Hello Roumen,

There is partial work in snapshots regarding cross compile.
MinGW still does not work well.

I've created the following ticket:

But no progress has been made in determine what is wrong.
Anyway, I think you will find the current trunk snapshot to be a
better reference.

Just wanted to stop using MS compiler...

Best Regards,
Alon Bar-Lev.

On 6/26/07, Roumen Petrov via RT wrote:
> I would like to propose following patch to openssl-0.9.8e source (see
> attachment openssl-0.9.8e-mingw.patch.gz).
> This patch is intended to create executables compatible with other win32
> compilers.
> Modifications:
> ./Makefiles.shared:
> - link_o.cygwin(used to build engines): modified use def-files in case
> of mingw . As example def-files allow target to be linked without
> library to exist on build system (IMPORTS);
> - link_a.cygwin: modified to produce dlls that match library name in
> def-file.
> ./engines/Makefile:
> - installation is extended to handle mingw and add support for lib prefixes.
> also correct suffixes in code to be equal to description in comment
> before.
> ./Makefile.org:
> - install dlls for openssl libraries
> ./Configure:
> - "mingw" (cosmetic) : shared flag in not necessary;
> - $IsMK1MF=1 (fatal, fixed upsteam) : remove this line since it break
> mingw non-single makefile build;
> - option static-engine : allow mkdef.pl to work without extra arguments.
> This can be extended in future to be a configure option that allow
> static and dynamic engines to be build at same time.
> Note that gmp engine need patch too and ./README.ENGINE is obsolete.
> ./util/mkerr.pl (not mingw specific):
> - added 'extern "C" {' in case of c++ to match right curly-brackets at end
> ./crypto/x509/Makefile (not mingw specific):
> - MINFO is created without information for crypto/x509/ in makefile.one
> (files) target.
> Tests:
> The created on linux executables successfully replace openssl (msc 13.x)
> found at url below.
> All xmlsec (with openssl) DSig tests succeed on w2k.
> Questions after build:
> After build I compare results between an existing build (openssl
> 0.9.8a, msc 13.x) and new build (openssl 0.9.8e, gcc 3.4.5 mingw). The
> difference is attached an file "objdump_table-diff.gz".
> Result show that mingw build export more functions. I guess that this is
> normal since mingw build is for xxx.8e.
> Other difference is that engines in mingw build are dynamic while in msc
> - static. No idea why msc build
> (http://www.zlatkovic.com/libxml.en.html) is with static engines.
> Diff show that variables OSSL_DES_version and OSSL_libdes_version from
> crypto/des/des_ver.h are exported in msc while mingw build don't export
> them. File crypto/opensslconf.h in mingw build
> If a remember well borland compiler don't export variables. It seems to
> me that gcc (mingw) don't export too. So that should use
> OPENSSL_XXX_GLOBAL for both variables?
> "Configure" set EXPORT_VAR_AS_FN for some win32 targets(msc, borlang,
> mingw, but cigwin). Should "Configure" set EXPORT_VAR_AS_FN always if
> build is for shared win32 platform ?
> Roumen

__________________________________________________ ____________________
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager majordomo@openssl.org