Skip Menu |
 

This queue is for tickets about the Crypt-SSLeay CPAN distribution.

Report information
The Basics
Id: 61249
Status: resolved
Priority: 0/
Queue: Crypt-SSLeay

People
Owner: nanis [...] runu.moc.invalid
Requestors: stuart [...] morungos.com
Cc:
AdminCc:

Bug Information
Severity: Important
Broken in: 0.58
Fixed in: 0.64



Subject: Over-rigid library use on Win32 prevents dynamic libraries
Download (untitled) / with headers
text/plain 565b
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.
Download (untitled) / with headers
text/plain 969b
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.
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>
Download (untitled) / with headers
text/plain 1.5k
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.
> >
Download (untitled) / with headers
text/plain 2.8k
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.
> > > >
>


This service is sponsored and maintained by Best Practical Solutions and runs on Perl.org infrastructure.

Please report any issues with rt.cpan.org to rt-cpan-admin@bestpractical.com.