PAR::Packer regression (works in 5.38.0.1, not in 5.38.2.2)

[Yaribz]

It seems the pp utility no longer handles the DLLs added with -l parameter correctly in Strawberry Perl 5.38.2.2.

How to reproduce:

• Create file useIoSocketSsl.pl containing only following line:

  use IO::Socket::SSL;

• Generate binary using pp command:

  pp -C -l libcrypto-1_1-x64__.dll -l libssl-1_1-x64.dll -l zlib1.dll -o useIoSocketSsl.exe useIoSocketSsl.pl

• Copy the binary file on a Windows system where Strawberry Perl isn't installed (or temporarily rename the folder where Strawberry Perl is installed on current system to remove it from PATH)

• Try to run the useIoSocketSsl.exe file.

What happens if the binary file has been generated with Strawberry Perl 5.38.0.1: the binary runs just fine.

What happens if the binary file has been generated with Strawberry Perl 5.38.2.2:

Can't load 'C:\Users\login\AppData\Local\Temp\par-416e6f6e796d6f7573\temp-11472\inc\lib\auto\Net\SSLeay\SSLeay.xs.dll' for module Net::SSLeay: load_file:The specified module could not be found at <embedded>/DynaLoader.pm line 206.
  at <embedded>/PAR/Heavy.pm line 104.
Compilation failed in require at C:\Users\login\AppData\Local\Temp\par-416e6f6e796d6f7573\temp-11472\inc\lib/IO/Socket/SSL.pm line 19.
BEGIN failed--compilation aborted at C:\Users\login\AppData\Local\Temp\par-416e6f6e796d6f7573\temp-11472\inc\lib/IO/Socket/SSL.pm line 19.
Compilation failed in require at script/useIoSocketSsl.pl line 1.
BEGIN failed--compilation aborted at script/useIoSocketSsl.pl line 1.

Furthermore, the behavior is a bit different if the -C parameter is removed from the pp command line (to allow the generated binary to reuse extracted files): as long as the program has never been launched with Strawberry Perl binaries available in PATH, it will generate the same error. However, as soon as the program has been launched once with Strawberry Perl in PATH, then it will work correctly for all subsequent runs, even if Strawberry Perl is removed from PATH... With Strawberry Perl 5.38.0.1 there is no such problem, all is working correctly in all cases.

[shawnlaffan]

This is more likely to be an issue with either PAR::Packer or PAR.

The respective versions distributed with SP 5.38.0.1 are 1.058 and 1.018, while those with SP 5.38.2.2 are 1.019 and 1.059.

I can reproduce on SP 5.36.1.1 with the latest versions.

This PAR issue is possibly related: https://github.com/rschupp/PAR/issues/11. There is a fix for that but no new release yet.

[Yaribz]

Oh ok, thanks for the information and sorry for the misplaced + duplicate bug report then.

I thought I tested this but I guess I forgot to clean some temporary cache folder while doing so...