Darkwing has asked for the wisdom of the Perl Monks concerning the following question:

Hi monks,

i tried to pack an older perl application having a lot of local modules using App::FatPacker::Simple. But when i tried to run the packed script, I got a "Can't locate Local/Foo/Bar.pm in @INC" error. By reducing the code step by step, I finally found out that the problem is caused by Exception::Class which is used for the exceptions. Small example:

File ./local/Local/Foo.pm

package Local::Foo; use strict; use warnings; sub foo_func { print("This is the Foo module\n"); } 1;

File ./local/Local/Exception.pm (note that the round parens and their content are commented out after Exception::Class.)

package Local::Exception; use strict; use warnings FATAL => 'all'; use Exporter 'import'; our @EXPORT = qw(throw_local); use Exception::Class #( # 'Local::Exception' => # { # description => 'My local exception', # alias => 'throw_local' # } #) ; 1;

File main.pl:

use strict; use warnings; use Local::Exception; BEGIN{ use Data::Dumper; print("\n>>>\n", Dumper(\@INC), "\n<<<\n"); } use Local::Foo; Local::Foo::foo_func();

The output (using Strawberry Perl 5.26) is as expected:

$VAR1 = [ bless( { 'Local/Exception.pm' => '#line 8 "main.fatpack.pl" package Local::Exception;use strict;use warnings FATAL=>\'all\';use Ex +porter \'import\';our@EXPORT=qw(throw_local);use Exception::Class ;1; ', 'Local/Foo.pm' => '#line 12 "main.fatpack.pl" package Local::Foo;use strict;use warnings;sub foo_func {print("This i +s the Foo module\\n")}1; ' }, 'FatPacked::41105272' ), '.\\local', 'C:/Strawberry-perl-5.26.3.1-64bit/perl/site/lib', 'C:/Strawberry-perl-5.26.3.1-64bit/perl/vendor/lib', 'C:/Strawberry-perl-5.26.3.1-64bit/perl/lib' ]; <<< This is the Foo module

It is also correct for Strawberry Perl 5.14, 5.38 and Perl 5.34 on Ubuntu. But if i remove the comment chars changing Local::Exception to:

package Local::Exception; use strict; use warnings FATAL => 'all'; use Exporter 'import'; our @EXPORT = qw(throw_local); use Exception::Class ( 'Local::Exception' => { description => 'My local exception', alias => 'throw_local' } ) ; 1;

Then i get:

>>> $VAR1 = [ 'C:/Strawberry-perl-5.26.3.1-64bit/perl/vendor/lib/Exception +/Class.pm', '.\\local', 'C:/Strawberry-perl-5.26.3.1-64bit/perl/site/lib', 'C:/Strawberry-perl-5.26.3.1-64bit/perl/vendor/lib', 'C:/Strawberry-perl-5.26.3.1-64bit/perl/lib' ]; <<< Can't locate Local/Foo.pm in @INC (you may need to install the Local:: +Foo module) (@INC contains: C:/Strawberry-perl-5.26.3.1-64bit/perl/ve +ndor/lib/Exception/Class.pm .\local C:/Strawberry-perl-5.26.3.1-64bit +/perl/site/lib C:/Strawberry-perl-5.26.3.1-64bit/perl/vendor/lib C:/S +trawberry-perl-5.26.3.1-64bit/perl/lib) at main.fatpack.pl line 59. BEGIN failed--compilation aborted at main.fatpack.pl line 59.

The structure that fatpacker adds to @INC is gone causing the error. Basically the same error i get for 5.14 and 5.34. It only works for Strawberry Perl 5.38. Seems that something has been fixed in Perl between 5.34 and 5.38.

Is this a known problem? Is there a workaround for older Perl versions? It would be best if it worked for 5.14, but I could live with 5.34 as well.

  • Comment on Why causes Exception::Class a fat-packed perl application to fail (but works with 5.38)
  • Select or Download Code

Replies are listed 'Best First'.
Re: Why causes Exception::Class a fat-packed perl application to fail (but works with 5.38)
by cavac (Prior) on Jul 04, 2024 at 08:57 UTC

    It would be best if it worked for 5.14, but I could live with 5.34 as well.

    VersionRelease dateStatusHas unpatched security problems?
    5.14.42013-03-10End-Of-LifeYes
    5.34.32023-11-29End-Of-LifeMaybe. Somewhat unlikely to get patches.

    To me, it boggles the mind that someone would try to use a Perl version that has been unsupported, insecure and end-on-life for a decade now. What's next, running your companies website on an Windows NT server?

    What is the problem with running an up-to-date, supported version of Perl?

      In our company, there are servers running very old versions. I had to fight to stop being forced to support 5.10. They have agreed to support >= 5.14.

      Now they are starting creating docker containers. But for these, they have 5.34 only.

      However, i will do it without fatpacking.

        Make sure to document your objections in writing to the responsible person(s), dateable documents are best. Send them an email to the list of Perl security vulnerabilities, so the have no excuse of "i didn't know" if the fit hits the shan.

        If possible, you should also print your correspondance re. the security issues of old Perl versions on a color laser printer. Those printers usually encode some metadata in nearly invisible yellow dots all over the pages, this makes it easier to prove when the documents were printed. Just in case there IS a larger issue that leads to a lawsuit. Data breaches and similar things are hugely expensive, so the company might try to sue you as a scapegoat. Depending on your jurisdiction, you might even be held criminally liable, since you were knowingly running an insecure system.

        So be careful with this stuff.

        Sidenote: Personally, i always make sure i require the latest major Perl release in my commercial source code. This helps make sure that the systems HAVE to be upgraded ;-)

Re: Why causes Exception::Class a fat-packed perl application to fail (but works with 5.38)
by hippo (Archbishop) on Jul 04, 2024 at 10:51 UTC
    i tried to pack an older perl application having a lot of local modules using App::FatPacker::Simple.

    An obvious follow-up question is then: what happened when you tried with the non-simple App::FatPacker instead? Very often one finds that a *::Simple module ends up being too simple for the task at hand so it would be interesting to know how the full-fat module performed in its place.


    🦛

      Same problem with this tool.