Unusable Perl 5.36 build - compilation failures due to various dll files not loading

Perl
1

My Perl 5.36 build is unusable for various reasons. One of them being the failure to load various dll files (that do exist).

Can’t load ‘C:/Perl-5.36/site/lib/auto/GD/GD.dll’ for module GD: load_file:The specified module could not be found at C:/Perl-5.36/lib/DynaLoader.pm line 206.

causes compilation to fail for:
Image/Resize.pm

Can’t load ‘C:/Perl-5.36/site/lib/auto/Net/SSLeay/SSLeay.dll’ for module Net::SSLeay: load_file:The specified module could not be found at C:/Perl-5.36/lib/DynaLoader.pm line 206.

causes compilation to fail for:
IO/Socket/SSL.pm
Net/SMTP/SSL.pm
Net/SMTP/TLS.pm
Net/SMTP/TLS/ButMaintained.pm

2

Hello,

The project appears to be building - ActiveState
unless you are referencing anther project.

Or are you saying when running things locally your code is getting those errors?

3

It’s a ‘successful’ build that is unusable at runtime, hence I’ve shown errors that refer to the installation at C:\Perl-5.36.

4

Getting multiple dlls that won’t load could mean that you have a Security Suite or AntiVirus tool which is preventing dlls from loading if they are not in one of the controlled folders. Trying turning off your AntiMalware before you run the Perl script, and if that solves the problem you might be able to alter the configuration of your setup so that the cache folders are whitelisted instead.

5

I did not consider that because I do not have the same issue with Perl 5.28 on the same computer.

Just to be sure, I disabled security features. The issue persists.

Note:
When I am testing a build, I set the PATH environment variable appropriately for the build in use.

6

I wrote the code that uses Net/SMTP/TLS/ButMaintained.pm and Net/SMTP/SSL.pm a very long time ago, before Net::SMTP included support for TLS and SSL. I have rewritten my code to use Net::SMTP, but SSLeay.dll not loading (during compile phase when running a script) is still an issue because Net::SMTP uses IO::Socket::SSL, which uses Net::SSLeay.

I believe this issue is caused by some problem with the ActiveState Perl 5.36.0 and 5.36.1 builds, because I have updated my Perl 5.28 installation to use the latest version of Net::SMTP, IO::Socket::SSL and Net::SSLeay (using OpenSSL 3.1.1 libraries), and my code runs without any issues.

I suspect the issue with GD.dll not loading is also an ActiveState build issue. The latest version is 2.78, but the latest version that doesn’t cause the build to fail is 2.76.

7

“I set the PATH environment variable appropriately for the build in use”
What you need to set for 5.36 will be different from what you needed to set for 5.28 or older versions because the folder structure is different.

For 5.28 all that was needed was to add the (Perl)\bin folder to PATH.
For 5.32 and higher, you need to also add (Perl)\exec in front of that.

SSL and GD are both affected, as are other modules, if the exec folder is not on PATH.

8

I was hoping that I finally had the solution. I added the exec folder path to PATH, and ran a script that uses GD. I’m still seeing ‘can’t load GD.dll’.

What is required in the exec folder to make it work?

9

Hey onlyonelikeme,

Do you have a perl command to test this - (I am testing your build now)

use GD, seems to come up clean for me.

10

I have state activated your project, and this is the only path var that I am using:
Path=C:\Users\Administrator\AppData\Local\activestate\cache\b452197a\exec;

I ran process monitor to see which dlls are being used, they are here in my build:

C:\Users\Administrator\AppData\Local\activestate\cache\b452197a\bin\libgcc_s_seh-1.dll
C:\Users\Administrator\AppData\Local\activestate\cache\b452197a\bin\libstdc++-6.dll
C:\Users\Administrator\AppData\Local\activestate\cache\b452197a\bin\libwinpthread-1.dll
C:\Users\Administrator\AppData\Local\activestate\cache\b452197a\bin\perl536.dll
C:\Users\Administrator\AppData\Local\activestate\cache\b452197a\lib\auto\Fcntl\Fcntl.dll
C:\Users\Administrator\AppData\Local\activestate\cache\b452197a\site\lib\auto\GD\GD.dll
C:\Users\Administrator\AppData\Local\activestate\cache\b452197a\site\lib\auto\IO\IO.dll
C:\Users\Administrator\AppData\Local\activestate\cache\b452197a\usr\bin\iconv.dll
C:\Users\Administrator\AppData\Local\activestate\cache\b452197a\usr\bin\libbz2-1.dll
C:\Users\Administrator\AppData\Local\activestate\cache\b452197a\usr\bin\libgd.dll
C:\Users\Administrator\AppData\Local\activestate\cache\b452197a\usr\bin\libjpeg-62.dll
C:\Users\Administrator\AppData\Local\activestate\cache\b452197a\usr\bin\libpng16.dll
C:\Users\Administrator\AppData\Local\activestate\cache\b452197a\usr\bin\libzlib1.dll

These Windows system libraries are also being called:

C:\Windows\System32\KernelBase.dll
C:\Windows\System32\advapi32.dll
C:\Windows\System32\bcryptprimitives.dll
C:\Windows\System32\cryptbase.dll
C:\Windows\System32\gdi32.dll
C:\Windows\System32\gdi32full.dll
C:\Windows\System32\imm32.dll
C:\Windows\System32\kernel32.dll
C:\Windows\System32\msvcp_win.dll
C:\Windows\System32\msvcrt.dll
C:\Windows\System32\mswsock.dll
C:\Windows\System32\ntdll.dll
C:\Windows\System32\powrprof.dll
C:\Windows\System32\rpcrt4.dll
C:\Windows\System32\sechost.dll
C:\Windows\System32\tzres.dll
C:\Windows\System32\ucrtbase.dll
C:\Windows\System32\umpdc.dll
C:\Windows\System32\user32.dll
C:\Windows\System32\win32u.dll
C:\Windows\System32\winmm.dll
C:\Windows\System32\ws2_32.dll
C:\Windows\System32\wshqos.dll
C:\Windows\System32\wshunix.dll

C:\Windows\WinSxS\amd64_microsoft.windows.common-controls_6595b64144ccf1df_6.0.20348.1_none_88d3d41d702dedea\comctl32.dll

So you could set some additional ENV vars:

<cachedir>\bin
<cachedir>\usr\bin\

And if it’s not working:

<cachedir>\site\lib\auto\GD
<cachedir>\lib\auto\Fcntl

If it’s still not working, I would recommend running procmon which is a free windows download → Process Monitor - Sysinternals | Microsoft Learn
Set it to filter on: Process Name begins with perl Include and Path ends with dll Include

Drop filtered events, and clear the events.
Then run: perl -e "use GD";

You should be able to see the search for the needed dlls, You will see NAME NOT FOUND in results as the system looks for dlls, but as long as these are followed by a SUCCESS, the dll is loaded. This should help you determine exactly what the issue is.

11

Thanks for looking at the issue for me.

I have done as you suggested.

This is what I see in the Command Prompt window after perl -e “use GD”:

Can’t load ‘C:/Perl-5.36.1/site/lib/auto/GD/GD.dll’ for module GD: load_file:The specified module could not be found at C:/Perl-5.36.1/lib/DynaLoader.pm line 206.
at -e line 1.
Compilation failed in require at -e line 1.
BEGIN failed–compilation aborted at -e line 1.

Procmon shows dlls loaded successfully. Here’s the list:

C:\Perl-5.36.1\bin\libgcc_s_seh-1.dll
C:\Perl-5.36.1\bin\libstdc++-6.dll
C:\Perl-5.36.1\bin\libwinpthread-1.dll
C:\Perl-5.36.1\bin\perl.exe
C:\Perl-5.36.1\bin\perl536.dll
C:\Perl-5.36.1\lib\auto\Fcntl\Fcntl.dll
C:\Perl-5.36.1\site\lib\auto\GD\GD.dll
C:\Perl-5.36.1\site\lib\auto\IO\IO.dll
C:\Windows\System32\advapi32.dll
C:\Windows\System32\combase.dll
C:\Windows\System32\fltLib.dll
C:\Windows\System32\gdi32.dll
C:\Windows\System32\gdi32full.dll
C:\Windows\System32\guard64.dll
C:\Windows\System32\imm32.dll
C:\Windows\System32\kernel32.dll
C:\Windows\System32\KernelBase.dll
C:\Windows\System32\msvcp_win.dll
C:\Windows\System32\msvcrt.dll
C:\Windows\System32\ntdll.dll
C:\Windows\System32\ole32.dll
C:\Windows\System32\rpcrt4.dll
C:\Windows\System32\sechost.dll
C:\Windows\System32\SHCore.dll
C:\Windows\System32\shell32.dll
C:\Windows\System32\ucrtbase.dll
C:\Windows\System32\user32.dll
C:\Windows\System32\version.dll
C:\Windows\System32\win32u.dll
C:\Windows\System32\ws2_32.dll
C:\Windows\WinSxS\amd64_microsoft.windows.common-controls_6595b64144ccf1df_6.0.22000.120_none_9d947278b86cc467\comctl32.dll

The ‘can’t load dll’ message may be a misleading message, but clearly something is causing the compile phase to fail.

I used state checkout / --runtime-path , so the installation is in C:\Perl-5.36.1 (previously C:\Perl-5.36 when I created the topic), rather than in a subfolder of the user AppData\Local folder.

12

I see now that I did not do quite what that says. I added the exec path after the bin and site\bin paths. If I just put the exec folder or put it in front of the bin and site\bin folders, then the ‘can’t load dll’ issue goes away.

That’s great, but also it’s slightly annoying that information has only come to light via this forum.

The only information I have seen prior to responses here is:
‘For editors and other tooling use the executables at: C:\Perl-5.36.1\exec.’

I have seen nothing about the requirement for exec to be above bin and site\bin.

At times when I have temporarily had more than one version of Perl installed, I would sometimes put the path to the executable at the command prompt, e.g. C:\Perl64\bin\perl. I have been doing the same with Perl 5.36, but now I know it should be, for example, C:\Perl-5.36.1\exec\perl rather than C:\Perl-5.36.1\bin\perl, otherwise it may not work.

It seems that the perl executables with the same name in both exec and bin run in parallel. Let’s hope that doesn’t break anything then! Unfortunately, it does! Any scripts looking at perl processes now need a filter to remove the duplication. I’d better get to it!

13

The exec files are wrappers, which exist to permit a form of relocation on the fly. They are setting the env vars which used to be set up system wide, but they do it at run time. You should be able to remove the bin and site/bin folders from PATH unless you have custom files that are added to the runtime into those folders.
As wrappers, they don’t exactly run in parallel, but yes you would see two processes from Windows with the same names.
For your “two Perls on the system at the same time”, the State Tool accomplishes this by not setting anything permanently, and running “state shell” to switch between them on demand.

14

Thanks for that information.

In my case I can remove bin, but not site\bin.

15

I see that the ‘can’t load dll’ issues no longer occur if the usr\bin folder and the bin folder (rather than the exec folder) are included in PATH.

Am I likely to see any other downside to not using perl.exe in the exec folder?

Some documentation on what perl.exe in the exec folder does would be useful. I think it replaces a perl.bat in some earlier builds, so I am guessing it does some simple tasks like add executable locations to PATH.