| Subject: | Strawberry perl does not work correctly with OPENSSL_PREFIX |
| Date: | Thu, 22 Mar 2012 09:48:32 +0100 |
| To: | bug-Net-SSLeay [...] rt.cpan.org |
| From: | kmx <kmx [...] volny.cz> |
This is not critical bug as it affects only users trying to use
strawberry perl with other openssl version than strawberry perl comes
with (which is what I am trying now).
I want just to record info I have gathered.
Sample scenario:
Z:\Net-SSleay-src> set OPENSSL_PREFIX=z:/dev_openssl/gcc32-1.0.1-beta3
Z:\Net-SSleay-src> perl Makefile.PL
Z:\Net-SSleay-src> dmake test
Will end up with openssl (1.0.1) DLL not found (or worse loading DLL
from wrong openssl version)
Workaround for this is:
Z:\Net-SSleay-src> set OPENSSL_PREFIX=z:/dev_openssl/gcc32-1.0.1-beta3
Z:\Net-SSleay-src> set PATH=z:\dev_openssl\gcc32-1.0.1-beta3\bin;%PATH%
Z:\Net-SSleay-src> perl Makefile.PL
Z:\Net-SSleay-src> dmake test
However we still have an issue as the resulting SSLeay.DLL is wrongly
linked (unfortunately without an error, unfortunately it is "somehow"
working)
The trouble is with linker option detection routines passes the
following LIBS option to ExtUtils::MakeMaker:
LIBS => [q[-Lz:/dev_openssl/gcc32-1.0.1-beta3
-Lz:/dev_openssl/gcc32-1.0.1-beta3/lib
-Lz:/dev_openssl/gcc32-1.0.1-beta3/out32dll
-Lz:/dev_openssl/gcc32-1.0.1-beta3/lib/VC -llibeay32MD -lssleay32MD
-llibeay32 -lssleay32 -llibssl32]]
which subsequently ExtUtils::MakeMaker turns into this g++ command
(added newlines to make it more clear):
g++ -o blib\arch\auto\Net\SSLeay\SSLeay.dll -Wl,--base-file -Wl,dll.base
-mdll -s
-L"Z:\strawberry32\perl\lib\CORE"
-L"Z:\strawberry32\c\lib" SSLeay.o
Z:\strawberry32\perl\lib\CORE\libperl514.a
z:\dev_openssl\gcc32-1.0.1-beta3\lib\libeay32.a
Z:\strawberry32\c\lib\libssleay32.a <<<<<<< this is a trouble
z:\dev_openssl\gcc32-1.0.1-beta3\lib\libssl32.a
Z:\strawberry32\c\i686-w64-mingw32\lib\libmoldname.a
Z:\strawberry32\c\i686-w64-mingw32\lib\libkernel32.a
... many other Win32 related *.a
Z:\strawberry32\c\i686-w64-mingw32\lib\libcomctl32.a
dll.exp
The workaroud was to temporarily remove/rename
Z:\strawberry32\c\lib\libssleay32.a
The proper fix should be IMHO improving library detection routine
SSLeay() in ext/Module/Install/PRIVATE/Net/SSLeay.pm
Unfortunately the fix will not be easy due to chaos in naming of
libraries (*.a) for Win32+gcc/mingw. The trouble is that openssl has 2
different way for building MSWindows/gcc libraries - one via
Configure+make; the second via mingw32.bat. Unfortunately each way
creates *.a files with different names
*/ Configure+make creates
- libcrypto.dll.a
- libcrypto.a
- libssl.dll.a
- libssl.a
*/ mingw32.bat creates
- libeay32.a (= libcrypto.dll.a)
- libcrypto.a
- libssl32.a (= libssl.dll.a)
- libssl.a
On top of that you have also MS compiler (cl/msvc) in MS Windows world
which uses also different library names: libeay32*.lib ssleay32*.lib
(from here probably comes "-lssleay32 -llibeay32" and "-llibeay32MD
-lssleay32MD" which should be fine with MS compiler).
Things get a little bit more complicated by the fact that the
more-or-less official openssl Win32 binaries distribution (see
http://www.openssl.org/related/binaries.html) contains also mingw/gcc
*.a libraries - however named: libeay32.a + ssleay32.a (which does not
correspond to the results produced by the mingw.bat from official
openssl tarball). Please note that ssleay32.a is not libssleay32.a thus
gcc linker will not find it when given -lssleay32
On top of that strawberry perl duplicates libssl32.a to libssleay32.a
to satisfy some perl modules with hardcoded -lssleay32 options (this is
exactly the reason of the troubles above)
--
kmx
P.S. The good news is that Net::SSLeay svn rev324 builds fine + passes
all tests with openssl-1.0.1-beta3