Hello Roumen,
There is partial work in snapshots regarding cross compile.
MinGW still does not work well.
I've created the following ticket:
http://rt.openssl.org/Ticket/Display.html?id=1451user=guestpass=guest
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 [EMAIL PROTECTED] 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
define OPENSSL_EXPORT_VAR_AS_FUNCTION .
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 [EMAIL PROTECTED]
