Bug #61324 for Crypt-SSLeay: Broken for *static* (also) openssl builds on Win32

Tue Sep 14 05:42:21 2010 sisyphus [...] cpan.org - Ticket created

Subject:

Broken for *static* (also) openssl builds on Win32

Hi Sinan, The report at https://rt.cpan.org/Ticket/Display.html?id=61249 is definitely pertinent. I considered adding my comments to it, rather than opening a fresh bug report - but I'm building Crypt::SSLeay 0.58 on Win32 (x64) against a *static* (MinGW64-built) openssl library, and that other report was concerned only with *dynamic* openssl. I couldn't get anywhere with the Makefile.PL that ships with the Crypt::SSLeay 0.58 source. Here's the Makefile.PL that I ended up using: ################################### use ExtUtils::MakeMaker; WriteMakefile( NAME => 'Crypt::SSLeay', AUTHOR => 'A. Sinan Unur <nanis@cpan.org>', ABSTRACT_FROM => 'SSLeay.pm', VERSION_FROM => 'SSLeay.pm', LIBS => '-LC:/_64/msys/1.0/local/lib -lz - LC:/_64/msys/1.0/local/ssl/lib -lssl -lcrypto', INC => "-IC:/_64/msys/1.0/local/ssl/include", clean => { FILES => 'crypt_ssleay_version.h test.config', }, ); ################################### I doubt that the 'clean' entry makes sense - it's just something that was left there after I copied stuff from the original Makefile.PL. Both of those paths in the LIBS entry are in my $Config{libpth} and the path that's specified in INC is in my $ENV{CPATH}. In addition to that, in SSLeay.xs, I replaced: #include "crypt_ssleay_version.h" with: ################################# #include <openssl/pkcs12.h> #include <openssl/ssl.h> #include <openssl/crypto.h> #define CRYPT_SSLEAY_free OPENSSL_free ################################# (Is there really a need for the Makefile.PL to determine what CRYPT_SSLEAY_free needs to be set to ? Couldn't the xs file examine the OpenSSL version and handle that all by itself ?) It then built, tested and installed fine. What annoyed me the most is that I had to rewrite (and wade through) so much. Given that MinGW will by default find headers that are in $ENV {CPATH} and that the relevant libraries were to be found in $Config {libpth}, I believe I should not have been subjected to so much frustration. Anyway, I got there in the end - and I'm happy to happy to help out further if I can. (Just let me know.) Cheers, Rob

Tue Sep 14 08:32:23 2010 nanis [...] runu.moc.invalid - Correspondence added

Hi Rob: The current Makefile.PL is a re-write of the previous one. It helped me understand what was going on to try to factor out bits and pieces. The next version will be simpler. My aim with 0.58 was to mainly understand and disentangle. My goal for 0.59 version is to streamline Makefile.PL and for 0.60 is to incorporate threading support. I do not have access to a 64-bit Windows machine, so reports like yours are especially valuable. Could you also tell me which version of OpenSSL you are using? I will give you a heads up when I have something ready to be tested. That should be in about two weeks' time. Thank you again for your help & input. -- Sinan On Tue Sep 14 05:42:21 2010, SISYPHUS wrote: Show quoted text

> Hi Sinan, > > The report at https://rt.cpan.org/Ticket/Display.html?id=61249 is > definitely pertinent. I considered adding my comments to it, rather > than opening a fresh bug report - but I'm building Crypt::SSLeay 0.58 > on Win32 (x64) against a *static* (MinGW64-built) openssl library, and > that other report was concerned only with *dynamic* openssl. > > I couldn't get anywhere with the Makefile.PL that ships with the > Crypt::SSLeay 0.58 source. Here's the Makefile.PL that I ended up using: > > ################################### > use ExtUtils::MakeMaker; > > WriteMakefile( > NAME => 'Crypt::SSLeay', > AUTHOR => 'A. Sinan Unur <nanis@cpan.org>', > ABSTRACT_FROM => 'SSLeay.pm', > VERSION_FROM => 'SSLeay.pm', > LIBS => '-LC:/_64/msys/1.0/local/lib -lz - > LC:/_64/msys/1.0/local/ssl/lib -lssl -lcrypto', > INC => "-IC:/_64/msys/1.0/local/ssl/include", > clean => { > FILES => 'crypt_ssleay_version.h test.config', > }, > ); > ################################### > > I doubt that the 'clean' entry makes sense - it's just something that > was left there after I copied stuff from the original Makefile.PL. > > Both of those paths in the LIBS entry are in my $Config{libpth} and the > path that's specified in INC is in my $ENV{CPATH}. > > In addition to that, in SSLeay.xs, I replaced: > > #include "crypt_ssleay_version.h" > > with: > > ################################# > #include <openssl/pkcs12.h> > #include <openssl/ssl.h> > #include <openssl/crypto.h> > > #define CRYPT_SSLEAY_free OPENSSL_free > ################################# > > (Is there really a need for the Makefile.PL to determine what > CRYPT_SSLEAY_free needs to be set to ? Couldn't the xs file examine the > OpenSSL version and handle that all by itself ?) > > It then built, tested and installed fine. > > What annoyed me the most is that I had to rewrite (and wade through) so > much. Given that MinGW will by default find headers that are in $ENV > {CPATH} and that the relevant libraries were to be found in $Config > {libpth}, I believe I should not have been subjected to so much > frustration. > > Anyway, I got there in the end - and I'm happy to happy to help out > further if I can. (Just let me know.) > > Cheers, > Rob

Tue Sep 14 08:32:24 2010 The RT System itself - Status changed from 'new' to 'open'

Tue Sep 14 08:32:37 2010 nanis [...] runu.moc.invalid - Taken

Tue Sep 14 20:36:31 2010 sisyphus [...] cpan.org - Correspondence added

On Tue Sep 14 08:32:23 2010, NANIS wrote: Show quoted text

> Hi Rob: > > The current Makefile.PL is a re-write of the previous one. It helped

me Show quoted text

> understand what was going on to try to factor out bits and pieces.

Yes, wading through Makfile.PL's these days is often not a simple task, these days :-) Show quoted text

> The next version will be simpler.

The Makefile.PL that I used (above) can, of course, be simplified to: ################### use ExtUtils::MakeMaker; WriteMakefile( NAME => 'Crypt::SSLeay', AUTHOR => 'A. Sinan Unur <nanis@cpan.org>', ABSTRACT_FROM => 'SSLeay.pm', VERSION_FROM => 'SSLeay.pm', LIBS => '-lz -lssl -lcrypto', ); ######################### I think that would also work if I built against a dynamic openssl library. The '-lz' would not be needed, but shouldn't cause a problem - and if MakeMaker couldn't find -lz, it would just remove it without making any fuss. Show quoted text

> I do not have access to a 64-bit Windows machine, so reports like

yours Show quoted text

> are especially valuable.

It's the same for 32-bit Windows. The above Makefile.PL, along with the changes to the SSLeay.xs (mentioned earlier) works fine for both my x86 and x64 builds of perl 5.12.2. Show quoted text

> Could you also tell me which version of OpenSSL you are using?

Currently using 0.9.8n, built (by me) from source in the MSYS shell using mingw32 for the 32-bit build and MinGW64 for the 64-bit build. I'm using the x86 and x64 builds of ActivePerl build 1202 (5.12.2), with the mingw32 (gcc-3.4.5) and MinGW64 (gcc-4.6.0) compilers respectively. With Strawberry Perl, there appears to be 3 openssl import libraries - named libeay32.a, libssl32.a and libssl32eay.a, though the last 2 are identical to each other. My Strawberry uses version 0.9.8l of the openssl library, and I don't have to make any additional alterations (other than the ones mentioned previously) to SSLeay.xs in order for it to build Crypt-SSLeay-0.58. For a Makefile.PL that works with both Strawberry-5.12.1 (x86 and x64) and my ActivePerl-5.12.2 (x86 and x64) the following works fine: ####################################### use ExtUtils::MakeMaker; WriteMakefile( NAME => 'Crypt::SSLeay', AUTHOR => 'A. Sinan Unur <nanis@cpan.org>', ABSTRACT_FROM => 'SSLeay.pm', VERSION_FROM => 'SSLeay.pm', LIBS => '-lz -lssl -lcrypto -lssl32 -lssleay32 -leay32', ); ####################################### That of course relies on the libraries and headers being in locations that are found by default - otherwise, I could still use the same Makefile.PL, but would have to provide INC and LIBS command line arguments (or somesuch) so that the library could be found. Show quoted text

> I will give you a heads up when I have something ready to be tested. > That should be in about two weeks' time.

That would be fine. Cheers, Rob

Mon Aug 06 07:48:22 2012 nanis [...] runu.moc.invalid - Correspondence added

Hi Rob: In the spirit of your recommendation, I threw out all the guessing that was going on. If the OpenSSL headers and libraries are not in places where they would be found by default by your build tools, please set the appropriate environment variables before running `perl Makefile.PL`. For example, if you are using ActiveState Perl and MinGW installed using ppm, and you installed OpenSSL in `C:\opt\openssl-1.0.1c`, then you would issue the following commands to build `Crypt::SSLeay`: C:\temp\Crypt-SSLeay> set LIBRARY_PATH=C:\opt\openssl-1.0.1c\lib;%LIBRARY_PATH% C:\temp\Crypt-SSLeay> set CPATH=C:\opt\openssl-1.0.1c\include;%CPATH% C:\temp\Crypt-SSLeay> perl Makefile.PL --live-tests C:\temp\Crypt-SSLeay> dmake test If you are using a Microsoft compiler (keep in mind that `perl` and OpenSSL need to have been built using the same compiler as well), you would use: C:\temp\Crypt-SSLeay> set LIB=C:\opt\openssl-1.0.1c\lib;%LIB% C:\temp\Crypt-SSLeay> set INCLUDE=C:\opt\openssl-1.0.1c\include;%INCLUDE% C:\temp\Crypt-SSLeay> perl Makefile.PL --live-tests C:\temp\Crypt-SSLeay> nmake test I would appreciate it if you could try out 0.64. Thank you for your feedback. -- Sinan On Tue Sep 14 20:36:31 2010, SISYPHUS wrote: Show quoted text

> On Tue Sep 14 08:32:23 2010, NANIS wrote:

> > Hi Rob: > > > > The current Makefile.PL is a re-write of the previous one. It helped

> me

> > understand what was going on to try to factor out bits and pieces.

> > Yes, wading through Makfile.PL's these days is often not a simple task, > these days :-) >

> > The next version will be simpler.

> > The Makefile.PL that I used (above) can, of course, be simplified to: > > ################### > use ExtUtils::MakeMaker; > > WriteMakefile( > NAME => 'Crypt::SSLeay', > AUTHOR => 'A. Sinan Unur <nanis@cpan.org>', > ABSTRACT_FROM => 'SSLeay.pm', > VERSION_FROM => 'SSLeay.pm', > LIBS => '-lz -lssl -lcrypto', > ); > > ######################### > > I think that would also work if I built against a dynamic openssl > library. The '-lz' would not be needed, but shouldn't cause a problem - > and if MakeMaker couldn't find -lz, it would just remove it without > making any fuss. >

> > I do not have access to a 64-bit Windows machine, so reports like

> yours

> > are especially valuable.

> > It's the same for 32-bit Windows. The above Makefile.PL, along with the > changes to the SSLeay.xs (mentioned earlier) works fine for both my x86 > and x64 builds of perl 5.12.2. >

> > Could you also tell me which version of OpenSSL you are using?

> > Currently using 0.9.8n, built (by me) from source in the MSYS shell > using mingw32 for the 32-bit build and MinGW64 for the 64-bit build. > > I'm using the x86 and x64 builds of ActivePerl build 1202 (5.12.2), > with the mingw32 (gcc-3.4.5) and MinGW64 (gcc-4.6.0) compilers > respectively. > > With Strawberry Perl, there appears to be 3 openssl import libraries - > named libeay32.a, libssl32.a and libssl32eay.a, though the last 2 are > identical to each other. My Strawberry uses version 0.9.8l of the > openssl library, and I don't have to make any additional alterations > (other than the ones mentioned previously) to SSLeay.xs in order for it > to build Crypt-SSLeay-0.58. > > For a Makefile.PL that works with both Strawberry-5.12.1 (x86 and x64) > and my ActivePerl-5.12.2 (x86 and x64) the following works fine: > > ####################################### > use ExtUtils::MakeMaker; > > WriteMakefile( > NAME => 'Crypt::SSLeay', > AUTHOR => 'A. Sinan Unur <nanis@cpan.org>', > ABSTRACT_FROM => 'SSLeay.pm', > VERSION_FROM => 'SSLeay.pm', > LIBS => '-lz -lssl -lcrypto -lssl32 -lssleay32 -leay32', > ); > > ####################################### > > That of course relies on the libraries and headers being in locations > that are found by default - otherwise, I could still use the same > Makefile.PL, but would have to provide INC and LIBS command line > arguments (or somesuch) so that the library could be found. >

> > I will give you a heads up when I have something ready to be tested. > > That should be in about two weeks' time.

> > That would be fine. > > Cheers, > Rob

Mon Aug 06 07:48:23 2012 nanis [...] runu.moc.invalid - Status changed from 'open' to 'resolved'