Bug #61249 for Crypt-SSLeay: Over-rigid library use on Win32 prevents dynamic libraries

Fri Sep 10 14:49:44 2010 stuart [...] morungos.com - Ticket created

Subject:

Over-rigid library use on Win32 prevents dynamic libraries

The (complex) Makefile.PL is wired to only use libssl32 and libeay32 as library names. However, the dynamic library versions of openssl are generated as libcrypto.dll.a and libssl.dll.a, at least using MinGW. This makes the Makefile.PL fail. Ideally, Win32 should allow this as an option, but less ideally, at least there should be some way of avoiding this override so that user-specified library and include paths are allowed. Normally I wouldn't mind, but I have about five other modules that also need openssl, so dynamic libraries are a sensible move.

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

Hello: Thank you for the report. This has been on my mind. I have been trying to think of a better way to organize Makefile.PL to solve this and a bunch of other related issues resulting from the "organic" growth of Makefile.PL. Expect a new development release in a couple of weeks which I hope you'd be willing to try out. -- Sinan On Fri Sep 10 14:49:44 2010, SNKWATT wrote: Show quoted text

> The (complex) Makefile.PL is wired to only use libssl32 and libeay32 as > library names. However, the dynamic library versions of openssl are > generated as libcrypto.dll.a and libssl.dll.a, at least using MinGW. This > makes the Makefile.PL fail. Ideally, Win32 should allow this as an

option, Show quoted text

> but less ideally, at least there should be some way of avoiding this > override so that user-specified library and include paths are allowed. > > Normally I wouldn't mind, but I have about five other modules that also > need openssl, so dynamic libraries are a sensible move.

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

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

Tue Sep 14 09:33:21 2010 stuart [...] morungos.com - Correspondence added

Subject:	Re: [rt.cpan.org #61249] Over-rigid library use on Win32 prevents dynamic libraries
Date:	Tue, 14 Sep 2010 09:33:09 -0400
To:	bug-Crypt-SSLeay [...] rt.cpan.org
From:	Stuart Watt <stuart [...] morungos.com>

No problem - and I look forward to it. Yours is by no means the only module. Part of me thinks there ought to be ExtUtils::Find::OpenSSL or something which can handle this for all the other OpenSSL modules. I probably reported it for this because you'd clearly put most work into finding openssl on Win32. Nobody else seemed to have tried as hard. All the best Stuart -- Stuart Watt stuart@morungos.com On 2010-09-14, at 8:19 AM, A. Sinan Unur via RT wrote: Show quoted text

> <URL: https://rt.cpan.org/Ticket/Display.html?id=61249 > > > Hello: > > Thank you for the report. > > This has been on my mind. I have been trying to think of a better way to > organize Makefile.PL to solve this and a bunch of other related issues > resulting from the "organic" growth of Makefile.PL. > > Expect a new development release in a couple of weeks which I hope you'd > be willing to try out. > > -- Sinan > > > On Fri Sep 10 14:49:44 2010, SNKWATT wrote:

>> The (complex) Makefile.PL is wired to only use libssl32 and libeay32 as >> library names. However, the dynamic library versions of openssl are >> generated as libcrypto.dll.a and libssl.dll.a, at least using MinGW. This >> makes the Makefile.PL fail. Ideally, Win32 should allow this as an

> option,

>> but less ideally, at least there should be some way of avoiding this >> override so that user-specified library and include paths are allowed. >> >> Normally I wouldn't mind, but I have about five other modules that also >> need openssl, so dynamic libraries are a sensible move.

> >

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

Hello: With 0.64, I removed all the code that was trying to guess compiler and linker options. If the headers and libraries are in non-standard places, you'll need to set the appropriate environment variables to ensure that they are found. 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 it out and provide any further feedback you might have. Thank you for your help and patience, -- Sinan On Tue Sep 14 09:33:21 2010, SNKWATT wrote: Show quoted text

> No problem - and I look forward to it. Yours is by no means the only > module. Part of me thinks there ought to be ExtUtils::Find::OpenSSL > or something which can handle this for all the other OpenSSL > modules. I probably reported it for this because you'd clearly put > most work into finding openssl on Win32. Nobody else seemed to have > tried as hard. > > All the best > Stuart > -- > Stuart Watt > stuart@morungos.com > > > > On 2010-09-14, at 8:19 AM, A. Sinan Unur via RT wrote: >

> > <URL: https://rt.cpan.org/Ticket/Display.html?id=61249 > > > > > Hello: > > > > Thank you for the report. > > > > This has been on my mind. I have been trying to think of a better

> way to

> > organize Makefile.PL to solve this and a bunch of other related

> issues

> > resulting from the "organic" growth of Makefile.PL. > > > > Expect a new development release in a couple of weeks which I hope

> you'd

> > be willing to try out. > > > > -- Sinan > > > > > > On Fri Sep 10 14:49:44 2010, SNKWATT wrote:

> >> The (complex) Makefile.PL is wired to only use libssl32 and

> libeay32 as

> >> library names. However, the dynamic library versions of openssl are > >> generated as libcrypto.dll.a and libssl.dll.a, at least using

> MinGW. This

> >> makes the Makefile.PL fail. Ideally, Win32 should allow this as an

> > option,

> >> but less ideally, at least there should be some way of avoiding

> this

> >> override so that user-specified library and include paths are

> allowed.

> >> > >> Normally I wouldn't mind, but I have about five other modules that

> also

> >> need openssl, so dynamic libraries are a sensible move.

> > > >

>

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

Mon Aug 06 07:45:16 2012 nanis [...] runu.moc.invalid - Fixed in 0.64 added