Could not find a suitable Class::Load implementation

Posted by ugo_t on 2014-03-20 03:03
Forums: PDK discussion | OS: Windows 7

I have a perl programs which works flawlessly on my computer, with Activestate perl 5.16.3 installed (32 bit, MS Windows 7, kernel 32 bit) and all the required modules.

I try to prepare a standalone executable with perlapp: the executable is created without any apparent issue. I run it in a separate console, and I get this error message.
Can't locate Path/Class/Entity.pm in @INC (@INC contains: ...
BEGIN failed--compilation aborted

That is easy: I explicitly include the module (in perlapp gui, menu Files, Added modules, ...)

I then make a new executable. Ok. When I run it, I get a slightly different error message:
Could not find a suitable Class::Load implementation: Can't locate Class/Load/XS.pm in @INC
...

Ok, that sounds easy.
perldoc -l Class::Load::XS
C:\Perl\site\lib\Class\Load\XS.pm
I have the missing module. Let's explicitly add this module, in the same way as I already did for Path::Class:Entity.

I rebuild the executable and I run it (always on the same machine).
I get the same error message as before! That is
Could not find a suitable Class::Load implementation: Can't locate Class/Load/XS.pm in @INC (@INC contains ...

And now I am stuck.
What should I do?
Why this module is still missing, even though I explicitly added it?

Regards,
Ugo

grahams
ActiveState Staff
Fri, 2014-03-21 15:31

Class::Load
Class::Load::XS

When you have a module that has both Pure Perl and XS versions, PerlApp can't tell which one will be needed ahead of time. Try including --add options for both versions, so that either path will have coverage.

ugo_t | Wed, 2014-03-26 05:39

Unfortunately your idea does not work.
I installed both Class::Load::XS and Class::Load::PP.
Both modules have been explicitly added, together with Class::Load, to the executable.

Again, when I create the executable, the file .exe is generated without any warnings.

And again, when I run the standalone executable, I get this error message one more time:
Could not find a suitable Class::Load implementation: Can't locate Class/Load/XS.pm in @INC (@INC contains ...

Note that a few weeks ago I was able to produce a working executable. I suspect that something went wrong with some recent update of the packages (I am using Moose).

I also tried to create an executable with PAR::Packer (installed through cpanm into ActiveState perl). Usually PAR::Packer works fine, but with this perl script I get a problem. The command pp creates the executable, as perlapp was doing, but when I run it, I get this error message:
> a.exe
Could not find a suitable B::Hooks::EndOfScope implementation: Can't locate Variable/Magic.pm in @INC (@INC contains: ...

Now I have no urgent issue with my script. I just hope that a future upgrade of PDK will make it perlapp work flawlessly, as it was always doing before.

grahams
ActiveState Staff
Tue, 2014-04-01 08:15

> I suspect that something went wrong with some recent update of the packages (I am using Moose).

This is very possible; Moose updates are known to introduce behaviours that PerlApp cannot predict. There are new heuristics in each PDK release for the iteration of Moose that was current during that PDK dev cycle, so try this again after 9.3 ships.

> (installed through cpanm into ActiveState perl)
- comment removed -
cpanm was not involved in any way.

ugo_t | Tue, 2014-04-01 09:35

Thank you for your replay.

I will try to follow your advice, but I am still quite happy of what I can achieve with Activestate Perl 5.16, by addidng some extra modules from cpan.

By the way, the program that I cannot compile with PerlApp works well with PAR::Packer, as long as I include some modules:
pp -M B::Hooks::EndOfScope::XS -M Variable::Magic myprogram.pl -o myprogram.exe
And, surprisingly, when I do it inside ActiveState perl 5.16 (perl 32 bit, Windows 32 bit) I get an executable as large as 5 Mbytes.
When I do exactly the same within Strawberry perl portable I get an executable of 12 Mbytes!

ugo_t | Wed, 2014-04-02 01:28

I carried on the work, and I see that the problem arise with PDK and CORE::require (at line 317 of Module::Runtime).
Surprisingly, I cannot post my long analysis on the forum because it triggers your spam filter!

Anyhow, to cut a long story short, when I include the missing modules inside perlapp, they are still missing. When I add statements like "use thismodule; use thatmodule;" in the main program, as an aid to perlapp, the error message changes, reporting other different missing modules.

grahams
ActiveState Staff
Wed, 2014-05-14 08:41

The 0.014 release causes PerlApp to be unable to wrap Class::Load correctly. It probably affects other modules as well, but Class::Load is usually the first victim.

For now, the best way to deal with this issue is to fall back to Module::Runtime 0.013, which is the default version supplied with 5.16.3.1603 and 1604.

markd@opmantek.com | Mon, 2014-05-19 18:37

I had the same problem and this solved it (on perl 5.16.3.1604). Pulling in the newest Moose had the side affect of grabbing a newer (and required) Module-Runtime.

removing the site versions like this:

sudo ppm remove --area site --force Module-Runtime
sudo ppm remove --area site Moose

The other way around may have made more sense. Anyhow, thanks!

stevenl | Tue, 2014-09-09 19:59

My Module::Runtime was still at 0.013 and I still had the problem. I had to remove Alt-Module-Runtime-ButEUMM instead.

ugo_t | Wed, 2014-12-10 08:12

Today I upgraded PDK to the new version, 9.4 (build 298593), without any change in my old perl installation and no update of any module.
It turns out that my code runs without problems (after adding manually just one module, but this is fine and predictable).
I cannot state whether PDK 9.4 fixes the problem with Module::Runtime; but I can report that my specific issue is gone :)