Skip Menu |
 

This queue is for tickets about the Perl-Dist-Strawberry CPAN distribution.

Report information
The Basics
Id: 131093
Status: open
Priority: 0/
Queue: Perl-Dist-Strawberry

People
Owner: Nobody in particular
Requestors: joseluis.martinez [...] capside.com
Cc:
AdminCc:

Bug Information
Severity: (no value)
Broken in: (no value)
Fixed in: (no value)



Subject: DLL loading directories
Date: Wed, 27 Nov 2019 10:26:23 +0000
To: "bug-Perl-Dist-Strawberry [...] rt.cpan.org" <bug-Perl-Dist-Strawberry [...] rt.cpan.org>
From: Jose Luis Martínez Torres <joseluis.martinez [...] capside.com>
Download (untitled) / with headers
text/plain 1.3k
Hi, We're starting to use the portable version of Strawberry Perl to distribute an application (instead of depending on Strawberry Perl being preinstalled on the system). Since the app depends on IO::Socket::SSL, OpenSSL gets compiled. When invoking our scripts, IO::Socket::SSL errors out saying it can't find a DLL. We're invoking wperl.exe directly (so we don't get DOS windows opened). The problem is basically that when invoking wperl.exe directly (or perl.exe also), the PATH is not set to STRAWBERRY_PATH\c\bin\, where the appropiate DLLs are (this is what is done by portableperl.bat, but we don't want to invoke portableperl.bat, since we get a DOS window opened). We've found that we can work around this issue by adding in out scripts the path to "\c\bin" in $ENV{PATH} before any DLL loading ocurrs. I'm wondering if there is a way to compile stuff with portable perl so that the PATH doesn't have to be set beforehand to "\c\bin". Can the destination of the compiled C libraries be controlled? (since I'd try to put them in a place where Windows searches by default). Maybe Portable Perl can do something to facilitate finding these DLLs in "\c\bin"? Windows does have a way to influence the places where DLLs are searched https://docs.microsoft.com/en-us/windows/win32/dlls/dynamic-link-library-search-order. Can we make this situation easier for users of Portable Perl? Best Regards, JLMARTIN
A "cheap" hack might be moving all c:\path_to_strawberry_folder\c\bin\*_.dll to c:\path_to_strawberry_folder\perl\bin\
Subject: RE: [rt.cpan.org #131093] DLL loading directories
Date: Wed, 27 Nov 2019 16:32:32 +0000
To: kmx via RT <bug-Perl-Dist-Strawberry [...] rt.cpan.org>
From: Jose Luis Martínez Torres <joseluis.martinez [...] capside.com>
Download (untitled) / with headers
text/plain 284b
Show quoted text
> A "cheap" hack might be moving all c:\path_to_strawberry_folder\c\bin\*_.dll to c:\path_to_strawberry_folder\perl\bin\
I tried that, as that was one of my first hunches, but it didn't work (I'm not sure why...). I'll try to do it again on a clean install just to confirm. Thanks!
Subject: RE: [rt.cpan.org #131093] DLL loading directories
Date: Fri, 29 Nov 2019 09:00:48 +0000
To: kmx via RT <bug-Perl-Dist-Strawberry [...] rt.cpan.org>
From: Jose Luis Martínez Torres <joseluis.martinez [...] capside.com>
Download (untitled) / with headers
text/plain 523b
Hi, I did a "copy STRAWBERRY_PATH\c\bin\*.dll STRAWBERRY_PATH\perl\bin\" on a vanilla install, and it doesn't work. Curiously there were some dlls in perl\bin with the same name. I tried without overwriting them and overwriting them: nothing: Perl still can't load the needed DLLs. Does anyone know the search order of DLLs that Portable Perl uses? Why does the same issue not happen with non-portable Perl? Where do the DLLs that get compiled end up in non-portable versions so that it finds them automatically?


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.