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
objdump_table-diff.gz
Description: application/gzip
openssl-0.9.8e-mingw.patch.gz
Description: application/gzip
