-l somelib.dll doesn't work in recent PAR::Packer versions

[patrickbkr]

I'm building App::Rakubrew.

This is the command I use to build the executable:

pp -I lib -M App::Rakubrew:: -M HTTP::Tinyish:: -M IO::Socket::SSL -l C:\Strawberry\c\bin\libcrypto-1_1-x64__.dll -l C:\Strawberry\c\bin\libssl-1_1-x64__.dll -l C:\Strawberry\c\bin\zlib1__.dll -o rakubrew.exe script/rakubrew

I'm on Windows 11.
Doing this on Strawberry 5.32.1.1 using PAR::Packer 1.057 works.

From what I can recall:
Using latest PAR::Packer (1.062) and any of Strawberry 5.32.1.1 doesn't work. (Not entirely sure anymore, but I think I tried on 5.36.3.1, 5.38.2.2 as well with same results.) The dll files are found in C:\Users\Patrick\AppData\Local\Temp\par-5061747269636b\cache-1d5b994e84508c42495b0ba2f77441f1887e19ff, but Dynaloader will fail to find the respective dll files. It does work when not renaming C:\strawberry\c\bin, it's then picking up the dlls in that folder (verified using the Sysinternals Process explorer). That folder is in PATH.

I do have a working setup, so it's not urgent. But I'd like to help get this sorted.
What next steps do I best take to track down the issue?

[rschupp]

The dll files are found in C:\Users\Patrick\AppData\Local\Temp\par-5061747269636b\cache-1d5b994e84508c42495b0ba2f77441f1887e19ff, but Dynaloader will fail to find the respective dll files

"The dll files" are libcrypto-1_1-x64__.dll, libssl-1_1-x64__.dll, and zlib1__.dll, right? DynaLoader doesn't look for them - it does load .../auto/Net/SSLeay/SSLeay.dll which is linked against them, but loading them is done by the Windows dynamic linker which searches for them along PATH. And your packed executable should see PATH=C:\Users\Patrick\AppData\Local\Temp\par-5061747269636b\cache-1d5b994e84508c42495b0ba2f77441f1887e19ff;...
You can check with

pp -o showpath.exe -E 'say qq[PATH=$ENV{PATH}]'
./showpath.exe

[patrickbkr]

"The dll files" are libcrypto-1_1-x64__.dll, libssl-1_1-x64__.dll, and zlib1__.dll, right?

Correct.

DynaLoader doesn't look for them - it does load .../auto/Net/SSLeay/SSLeay.dll which is linked against them, but loading them is done by the Windows dynamic linker which searches for them along PATH.

Right. Thanks for being clear about this. That helps.

And your packed executable should see PATH=C:\Users\Patrick\AppData\Local\Temp\par-5061747269636b\cache-1d5b994e84508c42495b0ba2f77441f1887e19ff;... You can check with

pp -o showpath.exe -E 'say qq[PATH=$ENV{PATH}]'
./showpath.exe

I've already dumped the PATH at the point of DynaLoader failing. That path wasn't in there. I assumed there must be some other mechanism that injects that path, but I actually observed the cause of the problem! Equipped with better knowledge, I can now do some more debugging. It's possible rakubrews code itself changes the path and thus breaks this. I do wonder why it works with the older PAR::Packer though.

[patrickbkr]

PS C:\Users\Patrick> pp --help
PAR Packager, version 1.062 (PAR version 1.020)

PS C:\Users\Patrick> No documentation found for "C:\Strawberry\perl\site\bin\pp.bat".
PS C:\Users\Patrick>
PS C:\Users\Patrick> pp -o showpath.exe -E 'say qq[PATH=$ENV{PATH}]'
PS C:\Users\Patrick> .\showpath.exe
PATH=C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem;C:\WINDOWS\System32\WindowsPowerShell\v1.0\;C:\WINDOWS\System32\OpenSSH\;C:\Program Files\Git\cmd;C:\Program Files\gettext-iconv\bin;C:\Strawberry\c\bin;C:\Strawberry\perl\site\bin;C:\Strawberry\perl\bin;C:\Users\Patrick\AppData\Local\Microsoft\WindowsApps;
PS C:\Users\Patrick> perl --version

This is perl 5, version 32, subversion 1 (v5.32.1) built for MSWin32-x64-multi-thread

Copyright 1987-2021, Larry Wall

Perl may be copied only under the terms of either the Artistic License or the
GNU General Public License, which may be found in the Perl 5 source kit.

Complete documentation for Perl, including FAQ lists, should be found on
this system using "man perl" or "perldoc perl".  If you have access to the
Internet, point your browser at http://www.perl.org/, the Perl Home Page.

PS C:\Users\Patrick>

So it's nothing to do with rakubrew.

[shawnlaffan]

See also: StrawberryPerl/Perl-Dist-Strawberry#168

The script in that issue is the single line use IO::Socket::SSL;, packed with the relevant DLLs. It runs with Strawberry Perl's dirs in the path, and fails without them.

[rschupp]

FWIW: The bug fixed by b1da0a5 was introduced in 2ac7078, 7 years ago (version 1.037), and is specific to Windows.
It's unlikely that nobody noticed until recently unless something else changed recently, e.g. Strawberry not configuring $Config{ldlibpthname}.

[patrickbkr]

@rschupp You really are quick in replying to and fixing bugs. Thank you very much!