Bug #131093 for Perl-Dist-Strawberry: DLL loading directories

Wed Nov 27 05:26:39 2019 joseluis.martinez [...] capside.com - Ticket created

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>

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

Wed Nov 27 11:02:53 2019 kmx [...] cpan.org - Correspondence added

A "cheap" hack might be moving all c:\path_to_strawberry_folder\c\bin\*_.dll to c:\path_to_strawberry_folder\perl\bin\

Wed Nov 27 11:02:54 2019 The RT System itself - Status changed from 'new' to 'open'

Wed Nov 27 11:32:50 2019 joseluis.martinez [...] capside.com - Correspondence added

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>

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!

Fri Nov 29 04:01:11 2019 joseluis.martinez [...] capside.com - Correspondence added

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>

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?