rschupp / par-packer Goto Github PK

Compilation failed in require at /loader/HASH(0x7fdba0884a10)/XSLoader.pm line 118.

Mode                LastWriteTime         Length Name
----                -------------         ------ ----
d-----         4/1/2021   5:33 PM                cache-93c4d81e1f9fc1ccb321da4d056f0d78e2a44841

Mode                LastWriteTime         Length Name
----                -------------         ------ ----
-a----         4/1/2021   5:33 PM          76288 libgcc_s_seh-1.dll
-a----         4/1/2021   5:33 PM        1424384 libstdc++-6.dll
-a----         4/1/2021   5:33 PM          52224 libwinpthread-1.dll
-a----         4/1/2021   5:33 PM          78848 parpacker_test.exe
-a----         4/1/2021   5:33 PM        3234816 perl530.dll

Mode                LastWriteTime         Length Name
----                -------------         ------ ----
d-----         4/1/2021   5:04 PM                cache-522d9f0811561fc3f902af2285fca57cbad3e26d
d-----         4/1/2021   5:04 PM                cache-71e892043d28332eab6e4f5d98e289b6c0ece2d5
d-----         4/1/2021   5:04 PM                cache-93c4d81e1f9fc1ccb321da4d056f0d78e2a44841

Mode                LastWriteTime         Length Name
----                -------------         ------ ----
-a----         4/1/2021   5:04 PM          76288 libgcc_s_seh-1.dll
-a----         4/1/2021   5:04 PM        1424384 libstdc++-6.dll
-a----         4/1/2021   5:04 PM          52224 libwinpthread-1.dll
-a----         4/1/2021   5:04 PM          78848 parlz4Vl.exe
-a----         4/1/2021   5:04 PM        3234816 perl530.dll

Mode                LastWriteTime         Length Name
----                -------------         ------ ----
-a----         4/1/2021   5:04 PM          13175 0086c683.pm
[for brevity, the remaining 87 .pm files like the one above were removed from the list.]
-a----         4/1/2021   5:04 PM          18432 36e8ac46.dll
-a----         4/1/2021   5:04 PM          47616 37ae5d86.dll
-a----         4/1/2021   5:04 PM         128000 434a9666.dll
-a----         4/1/2021   5:04 PM          54272 4ea903ad.dll
-a----         4/1/2021   5:04 PM          19456 77b87ac7.dll
-a----         4/1/2021   5:04 PM          73216 7b823064.dll
-a----         4/1/2021   5:04 PM         139264 93c4f6c2.dll
-a----         4/1/2021   5:04 PM          23552 b6881cac.dll
-a----         4/1/2021   5:04 PM          28160 b9fa593c.dll
-a----         4/1/2021   5:04 PM          23040 c501da06.dll
-a----         4/1/2021   5:04 PM          25088 dc43aa2b.dll
-a----         4/1/2021   5:04 PM          30208 e525790c.dll
-a----         4/1/2021   5:04 PM          67072 fb20c4cc.dll
-a----         4/1/2021   5:04 PM          20992 fcb949b8.dll
-a----         4/1/2021   5:04 PM          76288 libgcc_s_seh-1.dll
-a----         4/1/2021   5:04 PM        1424384 libstdc++-6.dll
-a----         4/1/2021   5:04 PM          52224 libwinpthread-1.dll
-a----         4/1/2021   5:04 PM          78848 parlloNY92L.exe
-a----         4/1/2021   5:04 PM        3234816 perl530.dll

Mode                LastWriteTime         Length Name
----                -------------         ------ ----
d-----         4/1/2021   5:04 PM                inc
-a----         4/1/2021   5:04 PM          13175 0086c683.pm
[for brevity, the remaining 87 .pm files like the one above were removed from the list.]
-a----         4/1/2021   5:04 PM          18432 36e8ac46.dll
-a----         4/1/2021   5:04 PM          47616 37ae5d86.dll
-a----         4/1/2021   5:04 PM         128000 434a9666.dll
-a----         4/1/2021   5:04 PM          54272 4ea903ad.dll
-a----         4/1/2021   5:04 PM            723 742afc26.pl
-a----         4/1/2021   5:04 PM          19456 77b87ac7.dll
-a----         4/1/2021   5:04 PM          73216 7b823064.dll
-a----         4/1/2021   5:04 PM            324 9137dde8.pl
-a----         4/1/2021   5:04 PM         139264 93c4f6c2.dll
-a----         4/1/2021   5:04 PM          23552 b6881cac.dll
-a----         4/1/2021   5:04 PM          28160 b9fa593c.dll
-a----         4/1/2021   5:04 PM          23040 c501da06.dll
-a----         4/1/2021   5:04 PM          25088 dc43aa2b.dll
-a----         4/1/2021   5:04 PM          30208 e525790c.dll
-a----         4/1/2021   5:04 PM          67072 fb20c4cc.dll
-a----         4/1/2021   5:04 PM          20992 fcb949b8.dll
-a----         4/1/2021   5:04 PM              0 inc.lock
-a----         4/1/2021   5:04 PM          76288 libgcc_s_seh-1.dll
-a----         4/1/2021   5:04 PM        1424384 libstdc++-6.dll
-a----         4/1/2021   5:04 PM          52224 libwinpthread-1.dll
-a----         4/1/2021   5:04 PM          78848 parpacker_test.exe
-a----         4/1/2021   5:04 PM        3234816 perl530.dll
-a----        3/31/2021   5:04 PM            183 _CANARY_.txt

[/opt/ActivePerl-5.16/site/bin]
$ ./cpanm PAR
--> Working on PAR
Fetching http://www.cpan.org/authors/id/R/RS/RSCHUPP/PAR-1.016.tar.gz ... OK
Configuring PAR-1.016 ... OK
==> Found dependencies: PAR::Dist
--> Working on PAR::Dist
Fetching http://www.cpan.org/authors/id/R/RS/RSCHUPP/PAR-Dist-0.51.tar.gz ... OK
Configuring PAR-Dist-0.51 ... OK
Building and testing PAR-Dist-0.51 ... OK
Successfully installed PAR-Dist-0.51
Building and testing PAR-1.016 ... OK
Successfully installed PAR-1.016
2 distributions installed

[/opt/ActivePerl-5.16/site/bin]
$ ./cpanm PAR::Packer
--> Working on PAR::Packer
Fetching http://www.cpan.org/authors/id/R/RS/RSCHUPP/PAR-Packer-1.051.tar.gz ... OK
Configuring PAR-Packer-1.051 ... OK
==> Found dependencies: Getopt::ArgvFile, IPC::Run3, Module::ScanDeps
--> Working on Getopt::ArgvFile
Fetching http://www.cpan.org/authors/id/J/JS/JSTENZEL/Getopt-ArgvFile-1.11.tar.gz ... OK
Configuring Getopt-ArgvFile-1.11 ... OK
Building and testing Getopt-ArgvFile-1.11 ... OK
Successfully installed Getopt-ArgvFile-1.11
--> Working on IPC::Run3
Fetching http://www.cpan.org/authors/id/R/RJ/RJBS/IPC-Run3-0.048.tar.gz ... OK
Configuring IPC-Run3-0.048 ... OK
Building and testing IPC-Run3-0.048 ... OK
Successfully installed IPC-Run3-0.048
--> Working on Module::ScanDeps
Fetching http://www.cpan.org/authors/id/R/RS/RSCHUPP/Module-ScanDeps-1.29.tar.gz ... OK
Configuring Module-ScanDeps-1.29 ... OK
Building and testing Module-ScanDeps-1.29 ... OK
Successfully installed Module-ScanDeps-1.29
Building and testing PAR-Packer-1.051 ... FAIL
! Installing PAR::Packer failed. See /root/.cpanm/work/1606926629.5013/build.log for details. Retry with --force to force install it.
3 distributions installed

[/opt/ActivePerl-5.16/site/bin]
$ ./cpanm PAR::Packer
--> Working on PAR::Packer
Fetching http://www.cpan.org/authors/id/R/RS/RSCHUPP/PAR-Packer-1.051.tar.gz ... OK
Configuring PAR-Packer-1.051 ... OK
Building and testing PAR-Packer-1.051 ... FAIL
! Installing PAR::Packer failed. See /root/.cpanm/work/1606926712.5624/build.log for details. Retry with --force to force install it.

cpanm (App::cpanminus) 1.7044 on perl 5.016003 built for i686-linux-thread-multi
Work directory is /root/.cpanm/work/1606926712.5624
You have make /usr/bin/make
You have LWP 6.15
You have /bin/tar: tar (GNU tar) 1.23
Copyright (C) 2010 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Written by John Gilmore and Jay Fenlason.
You have /usr/bin/unzip
Searching PAR::Packer () on cpanmetadb ...
--> Working on PAR::Packer
Fetching http://www.cpan.org/authors/id/R/RS/RSCHUPP/PAR-Packer-1.051.tar.gz
-> OK
Unpacking PAR-Packer-1.051.tar.gz
Entering PAR-Packer-1.051
Checking configure dependencies from META.json
Checking if you have ExtUtils::Embed 0 ... Yes (1.3001)
Checking if you have File::Glob 0 ... Yes (1.17)
Checking if you have File::Spec::Functions 0 ... Yes (3.40)
Checking if you have File::Basename 0 ... Yes (2.84)
Checking if you have DynaLoader 0 ... Yes (1.14)
Checking if you have ExtUtils::CBuilder 0 ... Yes (0.280212)
Configuring PAR-Packer-1.051
Running Makefile.PL
Checking if your kit is complete...
Looks good
Subroutine MY::postamble redefined at ./Makefile.PL line 230.
Use of uninitialized value $Config{"use64bitint"} in string eq at ./Makefile.PL line 197.
Generating a Unix-style Makefile
Writing Makefile for myldr
Generating a Unix-style Makefile
Writing Makefile for PAR::Packer
Writing MYMETA.yml and MYMETA.json
# using "ldd" to find shared libraries needed by ./par
-> OK
Checking dependencies from MYMETA.json ...
Checking if you have Compress::Zlib 1.30 ... Yes (2.063)
Checking if you have Archive::Zip 1.02 ... Yes (1.36)
Checking if you have ExtUtils::MakeMaker 0 ... Yes (6.84)
Checking if you have Getopt::ArgvFile 1.07 ... Yes (1.11)
Checking if you have IO::Compress::Gzip 0 ... Yes (2.063)
Checking if you have PAR 1.016 ... Yes (1.016)
Checking if you have Test::More 0 ... Yes (1.302181)
Checking if you have PAR::Dist 0.22 ... Yes (0.51)
Checking if you have Text::ParseWords 0 ... Yes (3.29)
Checking if you have File::Temp 0.05 ... Yes (0.2304)
Checking if you have Digest::SHA 5.40 ... Yes (5.85)
Checking if you have IPC::Run3 0.048 ... Yes (0.048)
Checking if you have Module::ScanDeps 1.21 ... Yes (1.29)
Building and testing PAR-Packer-1.051
cp lib/PAR/StrippedPARL/Base.pm blib/lib/PAR/StrippedPARL/Base.pm
cp lib/PAR/Packer.pm blib/lib/PAR/Packer.pm
cp lib/PAR/Filter/PodStrip.pm blib/lib/PAR/Filter/PodStrip.pm
cp lib/PAR/Filter/Obfuscate.pm blib/lib/PAR/Filter/Obfuscate.pm
cp lib/App/Packer/PAR.pm blib/lib/App/Packer/PAR.pm
cp lib/PAR/Filter.pm blib/lib/PAR/Filter.pm
cp lib/PAR/Filter/PatchContent.pm blib/lib/PAR/Filter/PatchContent.pm
cp lib/PAR/Filter/Bytecode.pm blib/lib/PAR/Filter/Bytecode.pm
cp lib/pp.pm blib/lib/pp.pm
cp lib/PAR/Filter/Bleach.pm blib/lib/PAR/Filter/Bleach.pm
make[1]: Entering directory `/root/.cpanm/work/1606926712.5624/PAR-Packer-1.051/myldr'
Makefile:860: warning: overriding commands for target `.c.o'
Makefile:345: warning: ignoring old commands for target `.c.o'
/opt/ActivePerl-5.16/bin/perl-static par_pl2c.pl my_par_pl < ../script/par.pl > my_par_pl.c 
gcc -c -D_REENTRANT -D_GNU_SOURCE -DUSE_SITECUSTOMIZE -DPERL_RELOCATABLE_INCPUSH -fno-merge-constants -fno-strict-aliasing -pipe -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64  -I/opt/ActivePerl-5.16/lib/CORE  -DLDLIBPTHNAME=\"LD_LIBRARY_PATH\" -DPARL_EXE=\"parl\" -DPAR_PACKER_VERSION=\"1.051\" -O2 main.c
gcc -c -D_REENTRANT -D_GNU_SOURCE -DUSE_SITECUSTOMIZE -DPERL_RELOCATABLE_INCPUSH -fno-merge-constants -fno-strict-aliasing -pipe -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64  -I/opt/ActivePerl-5.16/lib/CORE  -DLDLIBPTHNAME=\"LD_LIBRARY_PATH\" -DPARL_EXE=\"parl\" -DPAR_PACKER_VERSION=\"1.051\" -O2 -DBYTEORDER=0x1234 sha1.c
gcc main.o sha1.o  -s -Wl,-E -Wl,-rpath,/opt/ActivePerl-5.16/lib/CORE   -L/opt/ActivePerl-5.16/lib/CORE -lperl -lnsl -ldl -lm -lcrypt -lutil -lpthread -lc  -o ./par
/usr/bin/ld: skipping incompatible /opt/ActivePerl-5.16/lib/CORE/libperl.so when searching for -lperl
/usr/bin/ld: skipping incompatible /opt/ActivePerl-5.16/lib/CORE/libperl.a when searching for -lperl
/usr/bin/ld: cannot find -lperl
collect2: ld returned 1 exit status
make[1]: *** [par] Error 1
make[1]: Leaving directory `/root/.cpanm/work/1606926712.5624/PAR-Packer-1.051/myldr'
make: *** [subdirs] Error 2
-> FAIL Installing PAR::Packer failed. See /root/.cpanm/work/1606926712.5624/build.log for details. Retry with --force to force install it.

[/opt/ActivePerl-5.16/site/bin]
$ yum list installed | grep perl
perl.x86_64                        4:5.10.1-144.el6          @anaconda-RedHatEnterpriseLinux-201806150656.x86_64/6.10
perl-Archive-Extract.x86_64        1:0.38-144.el6            @anaconda-RedHatEnterpriseLinux-201806150656.x86_64/6.10
perl-Archive-Tar.x86_64            1.58-144.el6              @anaconda-RedHatEnterpriseLinux-201806150656.x86_64/6.10
perl-CGI.x86_64                    3.51-144.el6              @anaconda-RedHatEnterpriseLinux-201806150656.x86_64/6.10
perl-CPAN.x86_64                   1.9402-144.el6            @anaconda-RedHatEnterpriseLinux-201806150656.x86_64/6.10
perl-CPANPLUS.x86_64               0.88-144.el6              @anaconda-RedHatEnterpriseLinux-201806150656.x86_64/6.10
perl-Compress-Raw-Bzip2.x86_64     2.021-144.el6             @anaconda-RedHatEnterpriseLinux-201806150656.x86_64/6.10
perl-Compress-Raw-Zlib.x86_64      1:2.021-144.el6           @anaconda-RedHatEnterpriseLinux-201806150656.x86_64/6.10
perl-Compress-Zlib.x86_64          2.021-144.el6             @anaconda-RedHatEnterpriseLinux-201806150656.x86_64/6.10
perl-Crypt-SSLeay.x86_64           0.57-17.el6               @anaconda-RedHatEnterpriseLinux-201806150656.x86_64/6.10
perl-DBD-SQLite.x86_64             1.27-3.el6                @anaconda-RedHatEnterpriseLinux-201806150656.x86_64/6.10
perl-DBI.x86_64                    1.609-4.el6               @anaconda-RedHatEnterpriseLinux-201806150656.x86_64/6.10
perl-DBIx-Simple.noarch            1.32-3.el6                @anaconda-RedHatEnterpriseLinux-201806150656.x86_64/6.10
perl-Digest-SHA.x86_64             1:5.47-144.el6            @anaconda-RedHatEnterpriseLinux-201806150656.x86_64/6.10
perl-Error.noarch                  1:0.17015-4.el6           @anaconda-RedHatEnterpriseLinux-201806150656.x86_64/6.10
perl-ExtUtils-CBuilder.x86_64      1:0.27-144.el6            @anaconda-RedHatEnterpriseLinux-201806150656.x86_64/6.10
perl-ExtUtils-Embed.x86_64         1.28-144.el6              @anaconda-RedHatEnterpriseLinux-201806150656.x86_64/6.10
perl-ExtUtils-MakeMaker.x86_64     6.55-144.el6              @anaconda-RedHatEnterpriseLinux-201806150656.x86_64/6.10
perl-ExtUtils-ParseXS.x86_64       1:2.2003.0-144.el6        @anaconda-RedHatEnterpriseLinux-201806150656.x86_64/6.10
perl-File-Fetch.x86_64             0.26-144.el6              @anaconda-RedHatEnterpriseLinux-201806150656.x86_64/6.10
perl-Git.noarch                    1.7.1-10.el6_10           @rhel-6-server-rpms
perl-HTML-Parser.x86_64            3.64-2.el6                @anaconda-RedHatEnterpriseLinux-201806150656.x86_64/6.10
perl-HTML-Tagset.noarch            3.20-4.el6                @anaconda-RedHatEnterpriseLinux-201806150656.x86_64/6.10
perl-IO-Compress-Base.x86_64       2.021-144.el6             @anaconda-RedHatEnterpriseLinux-201806150656.x86_64/6.10
perl-IO-Compress-Bzip2.x86_64      2.021-144.el6             @anaconda-RedHatEnterpriseLinux-201806150656.x86_64/6.10
perl-IO-Compress-Zlib.x86_64       2.021-144.el6             @anaconda-RedHatEnterpriseLinux-201806150656.x86_64/6.10
perl-IO-Zlib.x86_64                1:1.09-144.el6            @anaconda-RedHatEnterpriseLinux-201806150656.x86_64/6.10
perl-IPC-Cmd.x86_64                1:0.56-144.el6            @anaconda-RedHatEnterpriseLinux-201806150656.x86_64/6.10
perl-Locale-Maketext-Simple.x86_64 1:0.18-144.el6            @anaconda-RedHatEnterpriseLinux-201806150656.x86_64/6.10
perl-Log-Message.x86_64            1:0.02-144.el6            @anaconda-RedHatEnterpriseLinux-201806150656.x86_64/6.10
perl-Log-Message-Simple.x86_64     0.04-144.el6              @anaconda-RedHatEnterpriseLinux-201806150656.x86_64/6.10
perl-Module-Build.x86_64           1:0.3500-144.el6          @anaconda-RedHatEnterpriseLinux-201806150656.x86_64/6.10
perl-Module-CoreList.x86_64        2.18-144.el6              @anaconda-RedHatEnterpriseLinux-201806150656.x86_64/6.10
perl-Module-Load.x86_64            1:0.16-144.el6            @anaconda-RedHatEnterpriseLinux-201806150656.x86_64/6.10
perl-Module-Load-Conditional.x86_64
perl-Module-Loaded.x86_64          1:0.02-144.el6            @anaconda-RedHatEnterpriseLinux-201806150656.x86_64/6.10
perl-Module-Pluggable.x86_64       1:3.90-144.el6            @anaconda-RedHatEnterpriseLinux-201806150656.x86_64/6.10
perl-Object-Accessor.x86_64        1:0.34-144.el6            @anaconda-RedHatEnterpriseLinux-201806150656.x86_64/6.10
perl-Package-Constants.x86_64      1:0.02-144.el6            @anaconda-RedHatEnterpriseLinux-201806150656.x86_64/6.10
perl-Params-Check.x86_64           1:0.26-144.el6            @anaconda-RedHatEnterpriseLinux-201806150656.x86_64/6.10
perl-Parse-CPAN-Meta.x86_64        1:1.40-144.el6            @anaconda-RedHatEnterpriseLinux-201806150656.x86_64/6.10
perl-Pod-Escapes.x86_64            1:1.04-144.el6            @anaconda-RedHatEnterpriseLinux-201806150656.x86_64/6.10
perl-Pod-Simple.x86_64             1:3.13-144.el6            @anaconda-RedHatEnterpriseLinux-201806150656.x86_64/6.10
perl-SGMLSpm.noarch                1.03ii-21.el6             @anaconda-RedHatEnterpriseLinux-201806150656.x86_64/6.10
perl-Term-UI.x86_64                0.20-144.el6              @anaconda-RedHatEnterpriseLinux-201806150656.x86_64/6.10
perl-Test-Harness.x86_64           3.17-144.el6              @anaconda-RedHatEnterpriseLinux-201806150656.x86_64/6.10
perl-Test-Simple.x86_64            0.92-144.el6              @anaconda-RedHatEnterpriseLinux-201806150656.x86_64/6.10
perl-Time-HiRes.x86_64             4:1.9721-144.el6          @anaconda-RedHatEnterpriseLinux-201806150656.x86_64/6.10
perl-Time-Piece.x86_64             1.15-144.el6              @anaconda-RedHatEnterpriseLinux-201806150656.x86_64/6.10
perl-URI.noarch                    1.40-2.el6                @anaconda-RedHatEnterpriseLinux-201806150656.x86_64/6.10
perl-XML-Dumper.noarch             0.81-8.el6                @anaconda-RedHatEnterpriseLinux-201806150656.x86_64/6.10
perl-XML-Grove.noarch              0.46alpha-40.el6          @anaconda-RedHatEnterpriseLinux-201806150656.x86_64/6.10
perl-XML-Parser.x86_64             2.36-7.el6                @anaconda-RedHatEnterpriseLinux-201806150656.x86_64/6.10
perl-XML-Twig.noarch               3.34-1.el6                @anaconda-RedHatEnterpriseLinux-201806150656.x86_64/6.10
perl-core.x86_64                   5.10.1-144.el6            @anaconda-RedHatEnterpriseLinux-201806150656.x86_64/6.10
perl-devel.x86_64                  4:5.10.1-144.el6          @anaconda-RedHatEnterpriseLinux-201806150656.x86_64/6.10
perl-libs.x86_64                   4:5.10.1-144.el6          @anaconda-RedHatEnterpriseLinux-201806150656.x86_64/6.10
perl-libwww-perl.noarch            5.833-5.el6               @anaconda-RedHatEnterpriseLinux-201806150656.x86_64/6.10
perl-libxml-perl.noarch            0.08-10.el6               @anaconda-RedHatEnterpriseLinux-201806150656.x86_64/6.10
perl-parent.x86_64                 1:0.221-144.el6           @anaconda-RedHatEnterpriseLinux-201806150656.x86_64/6.10
perl-version.x86_64                3:0.77-144.el6            @anaconda-RedHatEnterpriseLinux-201806150656.x86_64/6.10

[/opt/ActivePerl-5.16/site/bin]
$ which perl
/opt/ActivePerl-5.16/bin/perl

Could not load program pp_rs6000_test
An offset in the .loader section header is too large.
Examine the .loader section header with the 'dump -Hv' command.

#! /usr/bin/env perl

use feature qw(say);
use strict;
use warnings;
use LWP::UserAgent;

my $ua = LWP::UserAgent->new();
my $res = $ua->get(
    'https://metacpan.org/pod/pp'
);
if ($res->is_success) {
    print "ok\n";
}
else {
    die $res->status_line;
}

$ perl /home/hakon/perlbrew/perls/perl-5.30.0/bin/pp_autolink.pl -o p2.exe p.pl
# Use of runtime loader module Module::Implementation detected.  Results of static scanning may be incomplete.
# Use of runtime loader module Module::Runtime detected.  Results of static scanning may be incomplete.
ldd /home/hakon/perlbrew/perls/perl-5.30.0/bin/../lib/5.30.0/x86_64-linux/auto/B/B.so
ldd /home/hakon/perlbrew/perls/perl-5.30.0/bin/../lib/5.30.0/x86_64-linux/auto/Compress/Raw/Bzip2/Bzip2.so
ldd /home/hakon/perlbrew/perls/perl-5.30.0/bin/../lib/5.30.0/x86_64-linux/auto/Compress/Raw/Zlib/Zlib.so
ldd /home/hakon/perlbrew/perls/perl-5.30.0/bin/../lib/5.30.0/x86_64-linux/auto/Cwd/Cwd.so
ldd /home/hakon/perlbrew/perls/perl-5.30.0/bin/../lib/5.30.0/x86_64-linux/auto/Data/Dumper/Dumper.so
ldd /home/hakon/perlbrew/perls/perl-5.30.0/bin/../lib/5.30.0/x86_64-linux/auto/Digest/MD5/MD5.so
ldd /home/hakon/perlbrew/perls/perl-5.30.0/bin/../lib/5.30.0/x86_64-linux/auto/Encode/Encode.so
ldd /home/hakon/perlbrew/perls/perl-5.30.0/bin/../lib/5.30.0/x86_64-linux/auto/Fcntl/Fcntl.so
ldd /home/hakon/perlbrew/perls/perl-5.30.0/bin/../lib/5.30.0/x86_64-linux/auto/File/Glob/Glob.so
ldd /home/hakon/perlbrew/perls/perl-5.30.0/bin/../lib/5.30.0/x86_64-linux/auto/I18N/Langinfo/Langinfo.so
ldd /home/hakon/perlbrew/perls/perl-5.30.0/bin/../lib/5.30.0/x86_64-linux/auto/IO/IO.so
ldd /home/hakon/perlbrew/perls/perl-5.30.0/bin/../lib/5.30.0/x86_64-linux/auto/List/Util/Util.so
ldd /home/hakon/perlbrew/perls/perl-5.30.0/bin/../lib/5.30.0/x86_64-linux/auto/MIME/Base64/Base64.so
ldd /home/hakon/perlbrew/perls/perl-5.30.0/bin/../lib/5.30.0/x86_64-linux/auto/POSIX/POSIX.so
ldd /home/hakon/perlbrew/perls/perl-5.30.0/bin/../lib/5.30.0/x86_64-linux/auto/Socket/Socket.so
ldd /home/hakon/perlbrew/perls/perl-5.30.0/bin/../lib/5.30.0/x86_64-linux/auto/Storable/Storable.so
ldd /home/hakon/perlbrew/perls/perl-5.30.0/bin/../lib/5.30.0/x86_64-linux/auto/mro/mro.so
ldd /home/hakon/perlbrew/perls/perl-5.30.0/bin/../lib/5.30.0/x86_64-linux/auto/re/re.so
ldd /home/hakon/perlbrew/perls/perl-5.30.0/lib/site_perl/5.30.0/x86_64-linux/auto/HTML/Parser/Parser.so
ldd /home/hakon/perlbrew/perls/perl-5.30.0/lib/site_perl/5.30.0/x86_64-linux/auto/Net/SSLeay/SSLeay.so
ldd /home/hakon/perlbrew/perls/perl-5.30.0/lib/site_perl/5.30.0/x86_64-linux/auto/Params/Validate/XS/XS.so
ldd /lib/x86_64-linux-gnu/libm.so.6
ldd /lib/x86_64-linux-gnu/libssl.so.1.1
ldd /lib/x86_64-linux-gnu/libpthread.so.0
ldd /lib/x86_64-linux-gnu/libdl.so.2
ldd /lib/x86_64-linux-gnu/libcrypto.so.1.1
Alien sys dlls added: 
Detected link list: --link /lib/x86_64-linux-gnu/libpthread.so.0 --link /lib/x86_64-linux-gnu/libm.so.6 --link /lib/x86_64-linux-gnu/libcrypto.so.1.1 --link /lib/x86_64-linux-gnu/libssl.so.1.1 --link /lib/x86_64-linux-gnu/libdl.so.2
CMD:pp --link /lib/x86_64-linux-gnu/libpthread.so.0 --link /lib/x86_64-linux-gnu/libm.so.6 --link /lib/x86_64-linux-gnu/libcrypto.so.1.1 --link /lib/x86_64-linux-gnu/libssl.so.1.1 --link /lib/x86_64-linux-gnu/libdl.so.2 -o p2.exe p.pl
# Use of runtime loader module Module::Implementation detected.  Results of static scanning may be incomplete.
# Use of runtime loader module Module::Runtime detected.  Results of static scanning may be incomplete.

$ ./p2.exe
/tmp/par-68616b6f6e64/cache-989af1af4fb03c158b4acd9bdb3bfa54daf511f5/p2.exe: /lib/x86_64-linux-gnu/libcrypt.so.1: version `XCRYPT_2.0' not found (required by /tmp/par-68616b6f6e64/cache-989af1af4fb03c158b4acd9bdb3bfa54daf511f5/p2.exe)
/tmp/par-68616b6f6e64/cache-989af1af4fb03c158b4acd9bdb3bfa54daf511f5/p2.exe: /lib/x86_64-linux-gnu/libm.so.6: version `GLIBC_2.29' not found (required by /tmp/par-68616b6f6e64/cache-989af1af4fb03c158b4acd9bdb3bfa54daf511f5/p2.exe)
/tmp/par-68616b6f6e64/cache-989af1af4fb03c158b4acd9bdb3bfa54daf511f5/p2.exe: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.28' not found (required by /tmp/par-68616b6f6e64/cache-989af1af4fb03c158b4acd9bdb3bfa54daf511f5/p2.exe)

#! /usr/bin/env perl

use strict;
use warnings;
use Mojo::Util;
print "Test Mojo\n";

$ pp -x -c test.pl

$ ./a.out
Unable to open html entities file (/tmp/par-68616b6f6e/cache-4ffe784165f1ecd36682b1718fe84200a6f323bc/inc/lib/Mojo/resources/html_entities.txt): No such file or directory at script/test.pl line 5.
Compilation failed in require at script/test.pl line 5.
BEGIN failed--compilation aborted at script/test.pl line 5.

Searching PAR::Packer () on cpanmetadb ...
--> Working on PAR::Packer
Fetching http://www.cpan.org/authors/id/R/RS/RSCHUPP/PAR-Packer-1.051.tar.gz
-> OK
Unpacking PAR-Packer-1.051.tar.gz
Entering PAR-Packer-1.051
Checking configure dependencies from META.json
Checking if you have File::Spec::Functions 0 ... Yes (3.78)
Checking if you have DynaLoader 0 ... Yes (1.47)
Checking if you have ExtUtils::Embed 0 ... Yes (1.35)
Checking if you have File::Glob 0 ... Yes (1.33)
Checking if you have File::Basename 0 ... Yes (2.85)
Checking if you have ExtUtils::CBuilder 0 ... Yes (0.280235)
Configuring PAR-Packer-1.051
Running Makefile.PL
Checking if your kit is complete...
Looks good
Subroutine MY::postamble redefined at ./Makefile.PL line 230.
Generating a gmake-style Makefile
Writing Makefile for PAR::Packer
Writing MYMETA.yml and MYMETA.json
# using "objdump" recursively to find DLLs needed by par.exe
-> OK
Checking dependencies from MYMETA.json ...
Checking if you have Text::ParseWords 0 ... Yes (3.30)
Checking if you have IPC::Run3 0.048 ... Yes (0.048)
Checking if you have PAR 1.016 ... Yes (1.016)
Checking if you have ExtUtils::MakeMaker 0 ... Yes (7.52)
Checking if you have Digest::SHA 5.40 ... Yes (6.02)
Checking if you have Compress::Zlib 1.16 ... Yes (2.096)
Checking if you have Test::More 0 ... Yes (1.302183)
Checking if you have IO::Compress::Gzip 0 ... Yes (2.096)
Checking if you have Module::ScanDeps 1.21 ... Yes (1.29)
Checking if you have File::Temp 0.05 ... Yes (0.2311)
Checking if you have Win32::Exe 0.17 ... Yes (0.17)
Checking if you have Getopt::ArgvFile 1.07 ... Yes (1.11)
Checking if you have PAR::Dist 0.22 ... Yes (0.51)
Checking if you have Archive::Zip 1.02 ... Yes (1.68)
Building and testing PAR-Packer-1.051
cp lib/pp.pm blib\lib\pp.pm
cp lib/PAR/Packer.pm blib\lib\PAR\Packer.pm
cp lib/PAR/Filter/Bytecode.pm blib\lib\PAR\Filter\Bytecode.pm
cp lib/App/Packer/PAR.pm blib\lib\App\Packer\PAR.pm
cp lib/PAR/Filter.pm blib\lib\PAR\Filter.pm
cp lib/PAR/Filter/PodStrip.pm blib\lib\PAR\Filter\PodStrip.pm
cp lib/PAR/Filter/Obfuscate.pm blib\lib\PAR\Filter\Obfuscate.pm
cp lib/PAR/StrippedPARL/Base.pm blib\lib\PAR\StrippedPARL\Base.pm
cp lib/PAR/Filter/PatchContent.pm blib\lib\PAR\Filter\PatchContent.pm
cp lib/PAR/Filter/Bleach.pm blib\lib\PAR\Filter\Bleach.pm
gmake[1]: Entering directory 'C:/Users/SRVC_T~1/.cpanm/work/1607303316.576/PAR-Packer-1.051/myldr'
Makefile:868: warning: overriding recipe for target '.c.o'
Makefile:340: warning: ignoring old recipe for target '.c.o'
"C:\Perl\perl\bin\perl.exe" par_pl2c.pl my_par_pl < ..\script\par.pl > my_par_pl.c 
gcc -c -DWIN32 -DWIN64 -D__USE_MINGW_ANSI_STDIO -DPERL_TEXTMODE_SCRIPTS -DPERL_IMPLICIT_CONTEXT -DPERL_IMPLICIT_SYS -DUSE_PERLIO -fwrapv -fno-strict-aliasing -mms-bitfields  -I"C:\Perl\perl\lib\CORE"  -DLDLIBPTHNAME=\"\" -DPARL_EXE=\"parl.exe\" -DPAR_PACKER_VERSION=\"1.051\" -s -O2 main.c
gcc: fatal error: no input files
compilation terminated.
gmake[1]: *** [Makefile:868: main.o] Error 1
gmake[1]: Leaving directory 'C:/Users/SRVC_T~1/.cpanm/work/1607303316.576/PAR-Packer-1.051/myldr'
gmake: *** [Makefile:543: subdirs] Error 2

➜  pptest perlbrew switch perl-5.28.2
➜  pptest pp -e ' $s = "\x{263a}";$s =~ tr/\x{263a}/A/;binmode (STDOUT,":utf8"); print "$s\n";'
➜  pptest ./a.out                    
Can't locate utf8_heavy.pl in @INC (@INC contains: /tmp/par-6368726973/cache-6817150d1a78c179aed179e242eeea07095ab2a7/inc/lib /tmp/par-6368726973/cache-6817150d1a78c179aed179e242eeea07095ab2a7/inc CODE(0x555817028ae8) CODE(0x55581703e120)) at /home/chris/perl5/perlbrew/perls/perl-5.28.2/lib/5.28.2/utf8.pm line 16.
➜  pptest pp -u -e ' $s = "\x{263a}";$s =~ tr/\x{263a}/A/;binmode (STDOUT,":utf8"); print "$s\n";'
➜  pptest ./a.out
A
➜  pptest perlbrew switch perl-5.32.0
➜  pptest pp -e ' $s = "\x{263a}";$s =~ tr/\x{263a}/A/;binmode (STDOUT,":utf8"); print "$s\n";'
➜  pptest ./a.out                    
A
➜  pptest pp -u -e ' $s = "\x{263a}";$s =~ tr/\x{263a}/A/;binmode (STDOUT,":utf8"); print "$s\n";'
/home/chris/perl5/perlbrew/perls/perl-5.32.0/bin/pp: Cannot find module utf8_heavy.pl (specified with -M)

Hi,

the following code in myldr/utils.c line 239 looks suspicious. Shouldn't PAR_TMPDIR also be unset?

    par_unsetenv("PERLIO");

    par_unsetenv("PAR_INITIALIZED");
    par_unsetenv("PAR_SPAWNED");
    par_unsetenv("PAR_TEMP");
    par_unsetenv("PAR_CLEAN");
    par_unsetenv("PAR_DEBUG");
    par_unsetenv("PAR_CACHE");
    par_unsetenv("PAR_PROGNAME");

    if ( (buf = par_getenv("PAR_GLOBAL_DEBUG")) != NULL ) {
        par_setenv("PAR_DEBUG", buf);
    }

    if ( (buf = par_getenv("PAR_GLOBAL_TMPDIR")) != NULL ) {
        par_setenv("PAR_TMPDIR", buf);
    }

    if ( (buf = par_getenv("PAR_GLOBAL_TEMP")) != NULL ) {
        par_setenv("PAR_TEMP", buf);
    }
    else if ( (buf = par_getenv("PAR_GLOBAL_CLEAN")) != NULL ) {
        par_setenv("PAR_CLEAN", buf);
    }

Mit freundlichen Grü�en				

Ralf

Plugin "HeaderCondition" missing, maybe you need to install it?
BEGIN failed--compilation aborted at script/script.pl line 6.

Hallo,

ich have a perl-script with __DATA__ inside.
I compile it with pp -f Bleach ... to exe.
After starting exe it crashes.

Without -f Bleach it works fine.

What can I do?



Best reguards


Rino Ingenito

Hessisches Landesamt für
Bodenmanagement und Geoinformation
Geodatenbereitstellung
Schaperstra�e 16
65195 Wiesbaden 	
Telefon:  +49 (611) 535 5583 
E-Mail:   [email protected]	

On 2021-01-06 09:13:16, [email protected] wrote:
> ich have a perl-script with __DATA__ inside.
> I compile it with pp -f Bleach ... to exe.
> After starting exe it crashes.

Really? No error message?

> What can I do?

Don't use bleach on your colorful scripts :)
Seriously, you should have seen something like

readline() on unopened filehandle DATA at (eval 1) line 8.

Due to the way Bleach is implemented, __DATA__ doesn't work.

Cheers, Roderich

use strict;
use warnings;
use LWP::UserAgent;

my $ua = LWP::UserAgent->new();
my $res = $ua->get( 'https://metacpan.org/pod/pp');
if ($res->is_success) {
  print "ok\n";
}
else {
  die $res->status_line;
}

pp -o p4.exe -x p.pl

501 Can't load 'C:\Users\hakon\AppData\Local\Temp\par-68616b6f6e\cache-2fc254075e68b8cca263637e29f9a640f6669c6a\c8c63bf2.xs.dll' for module Net::SSLeay: load_file:The specified module could not be found (LWP::Protocol::https not installed) at script/p.pl line 12.

pp -o p4.exe -x -vv p.pl | findstr Protocol/http
C:\Strawberry\perl\site\bin/pp: ... adding <string> as lib/LWP/Protocol/http.pm
C:\Strawberry\perl\site\bin/pp: ... adding <string> as lib/LWP/Protocol/https.pm

Hi,

I just found out why PAR::Packer-generated executables tend to crash when I interact with them after I started them some days ago and they stayed mostly idle in the task bar -- this also happened on Win7, but I analyzed it under Win10:

https://support.microsoft.com/en-us/help/4506040/temp-folder-with-logon-session-id-is-deleted-unexpectedly

You can imagine a program behaving strange or crashing when it wants to load modules, resources or data files from its PAR_TEMP directory, but everything but the already open DLLs has vanished. I don't know exactly which windows versions are affected, but I don't want to give programs to users that suddenly crash out of nowhere, they might lose trust into the programs.

I don't know if there can be a better solution than documenting this behaviour. Of course one can set PAR_GLOBAL_TEMP or PAR_GLOBAL_TMPDIR, but you have to use wrapper scripts or an installer that find a suitable directory on the user's machine and set the variables for the process or globally -- which a bit defeats the 'one executable, no installer, just double-click the file I gave you' purpose of PAR::Packer. So the workaround I found is (without the Win32API::File-doesn't-exist-on-non-Win32 handling):

  if ('CODE' eq ref $INC[-1] && $^O eq 'MSWin32' && !$ENV{PAR_GLOBAL_TEMP} && !$ENV{PAR_GLOBAL_TMPDIR}) {
    use File::Find;
    use Win32API::File qw(:ALL);
    #use threads;
    #(async
    {
      no warnings 'File::Find';
      find +{
	     no_chdir => 1,
	     wanted => sub {
	       # ignore result, handle stays open until program terminates
	       -f and createFile $_, 'r ke', 'rw';
	     },
	    }, $ENV{PAR_TEMP};
    }
    #)->detach;
  }

Is there a better way?

Mit freundlichen Grü�en
Ralf

This is related to https://rt.cpan.org/Public/Bug/Display.html?id=101800 

Shawn.


On Fri Jun 12 09:37:57 2020, [email protected] wrote:
> Hi,
> 
> I just found out why PAR::Packer-generated executables tend to crash
> when I interact with them after I started them some days ago and they
> stayed mostly idle in the task bar -- this also happened on Win7, but
> I analyzed it under Win10:
> 
> https://support.microsoft.com/en-us/help/4506040/temp-folder-with-
> logon-session-id-is-deleted-unexpectedly
> 
> You can imagine a program behaving strange or crashing when it wants
> to load modules, resources or data files from its PAR_TEMP directory,
> but everything but the already open DLLs has vanished. I don't know
> exactly which windows versions are affected, but I don't want to give
> programs to users that suddenly crash out of nowhere, they might lose
> trust into the programs.
> 
> I don't know if there can be a better solution than documenting this
> behaviour. Of course one can set PAR_GLOBAL_TEMP or PAR_GLOBAL_TMPDIR,
> but you have to use wrapper scripts or an installer that find a
> suitable directory on the user's machine and set the variables for the
> process or globally -- which a bit defeats the 'one executable, no
> installer, just double-click the file I gave you' purpose of
> PAR::Packer. So the workaround I found is (without the Win32API::File-
> doesn't-exist-on-non-Win32 handling):
> 
> if ('CODE' eq ref $INC[-1] && $^O eq 'MSWin32' &&
> !$ENV{PAR_GLOBAL_TEMP} && !$ENV{PAR_GLOBAL_TMPDIR}) {
>   use File::Find;
>   use Win32API::File qw(:ALL);
>   #use threads;
>   #(async
>   {
>     no warnings 'File::Find';
>     find +{
>            no_chdir => 1,
>            wanted => sub {
>              # ignore result, handle stays open until program
> terminates
>              -f and createFile $_, 'r ke', 'rw';
>            },
>           }, $ENV{PAR_TEMP};
>   }
>   #)->detach;
> }
> 
> Is there a better way?
> 
> Mit freundlichen Grü�en
> Ralf

Hi.

> This is related to https://rt.cpan.org/Public/Bug/Display.html?id=101800

Yes and no. _CANARY_.txt exists and the directory will be repopulated on the next start of the program, so there is no problem except having to unpack the files again between runs of the program. My problem on the other hand is, that I start the program and the files are deleted while it is running. My crude protection scheme (locking all of the files -- 3500 files in my case, which only works with Windows file handles since Perl only gets the 2048 file handles implemented by the Windows libc) only protects the files while the program is running, so _CANARY_.txt is still needed (and there is a short time window at the start of the program, inbetween starting the unpacking and locking the files, where files could still vanish if you are unlucky enough to have cleanmgr.exe run at exactly the same time.

Using a non-temp-directory would solve both problems but carries some problems on its own, see original message. Declaring %TEMP% to be a non-temp directory sounds strange. Raising the existence interval only makes it less bad, but doesn't solve it. Also you have to have administrator privilege for both.

I also thought about keeping the files fresh by manipulating their timestamps, that also doesn't really solve it, but reflects the truth that the files have been used very recently. The would be easy but time-consuming on startup (and make _CANARY_.txt obsolete). To solve the runtime problems you would have to spawn a parallel job to keep the files fresh every couple of hours.

In essence, the reason is the same, but I don't see a simultaneous solution for both aspects that doesn't require user oder administrator input.

Mit freundlichen Grü�en				

Ralf

On Fri Jun 12 21:35:12 2020, [email protected] wrote:
> Hi.
> 
> > This is related to
> > https://rt.cpan.org/Public/Bug/Display.html?id=101800
> 
> Yes and no. _CANARY_.txt exists and the directory will be repopulated
> on the next start of the program, so there is no problem except having
> to unpack the files again between runs of the program. My problem on
> the other hand is, that I start the program and the files are deleted
> while it is running. My crude protection scheme (locking all of the
> files -- 3500 files in my case, which only works with Windows file
> handles since Perl only gets the 2048 file handles implemented by the
> Windows libc) only protects the files while the program is running, so
> _CANARY_.txt is still needed (and there is a short time window at the
> start of the program, inbetween starting the unpacking and locking the
> files, where files could still vanish if you are unlucky enough to
> have cleanmgr.exe run at exactly the same time.
> 
> Using a non-temp-directory would solve both problems but carries some
> problems on its own, see original message. Declaring %TEMP% to be a
> non-temp directory sounds strange. Raising the existence interval only
> makes it less bad, but doesn't solve it. Also you have to have
> administrator privilege for both.
> 
> I also thought about keeping the files fresh by manipulating their
> timestamps, that also doesn't really solve it, but reflects the truth
> that the files have been used very recently. The would be easy but
> time-consuming on startup (and make _CANARY_.txt obsolete). To solve
> the runtime problems you would have to spawn a parallel job to keep
> the files fresh every couple of hours.
> 
> In essence, the reason is the same, but I don't see a simultaneous
> solution for both aspects that doesn't require user oder administrator
> input.
> 
> Mit freundlichen Grü�en
> 
> Ralf

Yes, the canary file only helps in cases where files are deleted between program runs or where files only need to be read at startup.  

The regular temp file cleanup will also impact all users in that the PAR archive needs to be unpacked each time it is cleaned up, causing a slow user experience for large archives at startup.

FWIW, I'd be OK if the default PAR_TEMP location was in the user's home dir or under C:\ProgramData ($ENV{PROGRAMDATA}).  The latter might have issues on shared machines depending on how the unpacked files are used, though.

Shawn.

On Fri Jun 12 22:04:55 2020, SLAFFAN wrote:
> On Fri Jun 12 21:35:12 2020, [email protected] wrote:
> > Hi.
> >
> > > This is related to
> > > https://rt.cpan.org/Public/Bug/Display.html?id=101800
> >
> > Yes and no. _CANARY_.txt exists and the directory will be repopulated
> > on the next start of the program, so there is no problem except
> > having
> > to unpack the files again between runs of the program. My problem on
> > the other hand is, that I start the program and the files are deleted
> > while it is running. My crude protection scheme (locking all of the
> > files -- 3500 files in my case, which only works with Windows file
> > handles since Perl only gets the 2048 file handles implemented by the
> > Windows libc) only protects the files while the program is running,
> > so
> > _CANARY_.txt is still needed (and there is a short time window at the
> > start of the program, inbetween starting the unpacking and locking
> > the
> > files, where files could still vanish if you are unlucky enough to
> > have cleanmgr.exe run at exactly the same time.
> >
> > Using a non-temp-directory would solve both problems but carries some
> > problems on its own, see original message. Declaring %TEMP% to be a
> > non-temp directory sounds strange. Raising the existence interval
> > only
> > makes it less bad, but doesn't solve it. Also you have to have
> > administrator privilege for both.
> >
> > I also thought about keeping the files fresh by manipulating their
> > timestamps, that also doesn't really solve it, but reflects the truth
> > that the files have been used very recently. The would be easy but
> > time-consuming on startup (and make _CANARY_.txt obsolete). To solve
> > the runtime problems you would have to spawn a parallel job to keep
> > the files fresh every couple of hours.
> >
> > In essence, the reason is the same, but I don't see a simultaneous
> > solution for both aspects that doesn't require user oder
> > administrator
> > input.
> >
> > Mit freundlichen Grü�en
> >
> > Ralf
> 
> Yes, the canary file only helps in cases where files are deleted
> between program runs or where files only need to be read at startup.
> 
> The regular temp file cleanup will also impact all users in that the
> PAR archive needs to be unpacked each time it is cleaned up, causing a
> slow user experience for large archives at startup.
> 
> FWIW, I'd be OK if the default PAR_TEMP location was in the user's
> home dir or under C:\ProgramData ($ENV{PROGRAMDATA}).  The latter
> might have issues on shared machines depending on how the unpacked
> files are used, though.
> 
> Shawn.

$ENV{APPDATA} would be better than $ENV{PROGRAMDATA}

It is easy enough to add to mktmpdir.c for Windows builds, so I can work up a PR if Roderich is in favour of the idea.  

Hi.

> > FWIW, I'd be OK if the default PAR_TEMP location was in the user's
> > home dir or under C:\ProgramData ($ENV{PROGRAMDATA}).  The latter
> > might have issues on shared machines depending on how the unpacked
> > files are used, though.
>
> $ENV{APPDATA} would be better than $ENV{PROGRAMDATA}
>
> It is easy enough to add to mktmpdir.c for Windows builds, so I can work up a PR if Roderich is in favour of the idea.  

What is your concept for getting rid of old PAR_TEMP locations once you get (or create) an updated version of the application or just stop using it? Explicit deinstallation (maybe by using a special argument or variable when calling this version)? An own version of 'delete old files' but with a longer timeout and using a better protocol for detecting the last use and removing only whole directories? Giving the user better hints than cryptic directory names with cryptic files in it, that he can decide which dirs to purge manually? This could be implemented by description files or by a version manager.

Explicit deinstallation could be paired with explicit installation -- the application only unpacks intelf into a permanent location, if you explicely tell it to do so, in a way every user understands.

Mit freundlichen Grü�en				

Ralf Neubauer

On Sat Jun 13 06:44:03 2020, [email protected] wrote:
> Hi.
> 
> > > FWIW, I'd be OK if the default PAR_TEMP location was in the user's
> > > home dir or under C:\ProgramData ($ENV{PROGRAMDATA}).  The latter
> > > might have issues on shared machines depending on how the unpacked
> > > files are used, though.
> >
> > $ENV{APPDATA} would be better than $ENV{PROGRAMDATA}
> >
> > It is easy enough to add to mktmpdir.c for Windows builds, so I can
> > work up a PR if Roderich is in favour of the idea.
> 
> What is your concept for getting rid of old PAR_TEMP locations once
> you get (or create) an updated version of the application or just stop
> using it? Explicit deinstallation (maybe by using a special argument
> or variable when calling this version)? An own version of 'delete old
> files' but with a longer timeout and using a better protocol for
> detecting the last use and removing only whole directories? Giving the
> user better hints than cryptic directory names with cryptic files in
> it, that he can decide which dirs to purge manually? This could be
> implemented by description files or by a version manager.
> 
> Explicit deinstallation could be paired with explicit installation --
> the application only unpacks intelf into a permanent location, if you
> explicely tell it to do so, in a way every user understands.
> 
> Mit freundlichen Grü�en
> 
> Ralf Neubauer


Currently there is no removal of old PAR archives that I am aware of.  Removal is left to the user or automated processes.  

It could be done manually using PAR_GLOBAL_CLEAN at the cost of running the exe.  e.g. for some_archive.exe this could be packed into an uninstall.bat:

  set PAR_GLOBAL_CLEAN=1
  some_archive.exe

Maybe this could be added to PAR so it does not run the exe and just does the cleanup, e.g.:

some_archive.exe --run-par-cleanup

It's probably conceptually simpler for the user if it is a separate process, though.  

It would also be possible to add that logic to your own perl script so it can exit without doing anything, but it might be too late by the time that is loaded.

On Sat Jun 13 18:45:02 2020, SLAFFAN wrote:
> On Sat Jun 13 06:44:03 2020, [email protected] wrote:
> > Hi.
> >
> > > > FWIW, I'd be OK if the default PAR_TEMP location was in the
> > > > user's
> > > > home dir or under C:\ProgramData ($ENV{PROGRAMDATA}).  The latter
> > > > might have issues on shared machines depending on how the
> > > > unpacked
> > > > files are used, though.
> > >
> > > $ENV{APPDATA} would be better than $ENV{PROGRAMDATA}
> > >
> > > It is easy enough to add to mktmpdir.c for Windows builds, so I can
> > > work up a PR if Roderich is in favour of the idea.
> >
> > What is your concept for getting rid of old PAR_TEMP locations once
> > you get (or create) an updated version of the application or just
> > stop
> > using it? Explicit deinstallation (maybe by using a special argument
> > or variable when calling this version)? An own version of 'delete old
> > files' but with a longer timeout and using a better protocol for
> > detecting the last use and removing only whole directories? Giving
> > the
> > user better hints than cryptic directory names with cryptic files in
> > it, that he can decide which dirs to purge manually? This could be
> > implemented by description files or by a version manager.
> >
> > Explicit deinstallation could be paired with explicit installation --
> > the application only unpacks intelf into a permanent location, if you
> > explicely tell it to do so, in a way every user understands.
> >
> > Mit freundlichen Grü�en
> >
> > Ralf Neubauer
> 
> 
> Currently there is no removal of old PAR archives that I am aware of.
> Removal is left to the user or automated processes.
> 
> It could be done manually using PAR_GLOBAL_CLEAN at the cost of
> running the exe.  e.g. for some_archive.exe this could be packed into
> an uninstall.bat:
> 
> set PAR_GLOBAL_CLEAN=1
> some_archive.exe
> 
> Maybe this could be added to PAR so it does not run the exe and just
> does the cleanup, e.g.:
> 
> some_archive.exe --run-par-cleanup
> 
> It's probably conceptually simpler for the user if it is a separate
> process, though.
> 
> It would also be possible to add that logic to your own perl script so
> it can exit without doing anything, but it might be too late by the
> time that is loaded.

I've run some testing and neither approach works.  When PAR_GLOBAL_TEMP is set before running the exe, the archive is unpacked into a different folder named like temp-12345 and cleaned up on exit.  Setting it in a BEGIN block within the packed script appears too late to have any effect.  Presumably the environment is localised or some other flag is set by PAR at startup to check on exit.

It looks like a separate uninstaller is needed, although it would need to ensure it does not remove files from under a running process, as otherwise it is another example of the original reported issue.

Shawn.

On 2020-06-13 02:59:53, SLAFFAN wrote:
> $ENV{APPDATA} would be better than $ENV{PROGRAMDATA}
> 
> It is easy enough to add to mktmpdir.c for Windows builds, so I can
> work up a PR if Roderich is in favour of the idea.

Go for it :) I suggest "$ENV{APPDATA}/Local/pp" and maybe we may omit the per-user sub directory
in this case (as %APPDATA% should already be per-user). Maybe drop the ancient fallback to C:\TEMP 
(and the really weird %WinDir%\temp) as well.

Keep in mind that par_mktmpdir in myldr/mktmpdir.c has a perl-level sibling _set_par_temp in script/par.pl.

Cheers, Roderich

On 2020-06-13 06:44:03, [email protected] wrote:
> What is your concept for getting rid of old PAR_TEMP locations once
> you get (or create) an updated version of the application or just stop
> using it?

There is none.

> Explicit deinstallation (maybe by using a special argument
> or variable when calling this version)? 

Nope. PAR::Packer is expressly designed to work WITHOUT installation and tacking on stuff
is out of the question - there are already too many special arguments/variables.
If you want installation/deinstallation look somewhere else.

Cheers, Roderich

Hi,

-----Original Message-----
From: Roderich Schupp via RT <[email protected]> 
>
> On 2020-06-13 06:44:03, [email protected] wrote:
> > What is your concept for getting rid of old PAR_TEMP locations once
> > you get (or create) an updated version of the application or just stop
> > using it?
>
> There is none.

This question was meant to be an answer  to Shawns ideas. He devised de-facto-installation and I wanted to hear the fully thought out story from him.
If the files are in %TEMP% someday someone will come along and clean up, because it is a known place for cleaning up potential. No one will look into Appdata/pp if the disk fills up. 

> > Explicit deinstallation (maybe by using a special argument
> > or variable when calling this version)? 
>
> Nope. PAR::Packer is expressly designed to work WITHOUT installation and tacking on stuff
> is out of the question - there are already too many special arguments/variables.
> If you want installation/deinstallation look somewhere else.

Unpacking into something else than %TEMP% is de facto installation. I don't want installation, but if the archive de facto installs itself into a hidden permanent directory, there should be some help for the user to keep the space usage under control. Sometimes I create new versions every couple of days and if people run that, their disks will fill up. Completely ignoring the problem means the deinstallation process is to manually clean the correct ones of a big collections of directories with cryptic names from a not-so-well-know subdirectory of Appdata. I read most of the source of the package and still hope there can be some middle ground to make it a bit easier for the users. One of my suggestions was to at least describe the contents of the directories, for every cache-xyz/ there could be a cache-xyz-description.txt which lists the name of the application, the date of unpacking. And maybe the timestamp of cache-xyz/ and cache-xyz-description.txt should be set to the current time every time the application is started, that would make it possible to find the old unused entries with a sorted directory listing.

As an alternative to Shawns solution you could also unpack into %TEMP% like before, but set a timestamp some interval (e.g. 6 months) in the future for all files every time the application starts, that would most likely also protect the files.

Mit freundlichen Grü�en				

Ralf

Hi Mr. Mueller,

When using pp to create a stanalone executable in activeperl for x64, if the source code used Parallel::Loops, the executable will crash and the following is the problem detail:

Problem signature:
  Problem Event Name:                        APPCRASH
  Application Name:                             pre-process-elt-x64.exe
  Application Version:                           0.0.0.0
  Application Timestamp:                     4e3026dd
  Fault Module Name:                          perl512.dll
  Fault Module Version:                        5.12.2.1203
  Fault Module Timestamp:                  4d009fe0
  Exception Code:                                  c0000005
  Exception Offset:                                000000000013eb35
  OS Version:                                          6.0.6002.2.2.0.18.10
  Locale ID:                                             1033
  Additional Information 1:                  98c4
  Additional Information 2:                  adc3265ea6226a0345ffdbdc4025017e
  Additional Information 3:                  360c
  Additional Information 4:                  f2486cf67a3bbd6d9170c007387206e1


Is this problem related to how fork in perl is handled in windows or is this problem only related to Parallel::Loops? But the perl code itself works without any problem.

Thank you very much for your attention.

Frank Wang


______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
______________________________________________________________________

On 2011-07-27 17:41:15, [email protected] wrote:
> When using pp to create a stanalone executable in activeperl for x64,
> if the source code used Parallel::Loops, the executable will crash and
> the following is the problem detail:

This information is useless.

Please provide a minimal code example that exhibits the problem.
Also include the output of "perl -V" and the versions of
PAR and PAR::Packer used.

> But the perl code itself works without any problem.

By that you mean: the code works when not packed?

Cheers, Roderich

Hi Roderich,

Yes the code work fine and fast when not packed. Only crash when run packed code.
The following is a minimal code example that exhibits the problem:

#!/usr/bin/perl
use strict;
use warnings;
use diagnostics;
$|=1;
my $workers=@ARGV ? shift : 16;
use Parallel::Loops;
my @modelfiles=("ct_125_gulfstream_ws_26119a.txt");
my $pl = Parallel::Loops->new($workers);
$pl->foreach(\@modelfiles, 
sub {	
  my $mf = $_;
  print $mf;
}
);

And this is the output of perl-V:

Set up gcc environment - 4.4.5 20101001 (release) [svn/rev.164871 - mingw-w64/oz]
Summary of my perl5 (revision 5 version 12 subversion 2) configuration:

  Platform:
    osname=MSWin32, osvers=5.2, archname=MSWin32-x64-multi-thread
    uname=''
    config_args='undef'
    hint=recommended, useposix=true, d_sigaction=undef
    useithreads=define, usemultiplicity=define
    useperlio=define, d_sfio=undef, uselargefiles=define, usesocks=undef
    use64bitint=define, use64bitall=undef, uselongdouble=undef
    usemymalloc=n, bincompat5005=undef
  Compiler:
    cc='gcc', ccflags =' -DNDEBUG -O2 -DWIN32 -D_CONSOLE -DNO_STRICT -DHAVE_DES_FCRYPT -DCONSERVATIVE -DUSE_SITECUSTOMIZE -DPRIVLIB_LAST_IN_INC -DPERL_IMPLI
CIT_CONTEXT -DPERL_IMPLICIT_SYS -DUSE_PERLIO -DPERL_MSVCRT_READFIX -DWIN64',
    optimize='-O2',
    cppflags='-DWIN32'
    ccversion='', gccversion='4.4.5 20101001 (release) [svn/rev.164871 - mingw-w64/oz]', gccosandvers=''
    intsize=4, longsize=4, ptrsize=8, doublesize=8, byteorder=12345678
    d_longlong=undef, longlongsize=8, d_longdbl=define, longdblsize=8
    ivtype='__int64', ivsize=8, nvtype='double', nvsize=8, Off_t='__int64', lseeksize=8
    alignbytes=8, prototype=define
  Linker and Libraries:
    ld='g++', ldflags ='-s -L"C:\Perl64\lib\CORE"'
    libpth="C:\mingw64\lib" "C:\mingw64\x86_64-w64-mingw32\lib"
    libs= -lmoldname -lkernel32 -luser32 -lgdi32 -lwinspool -lcomdlg32 -ladvapi32 -lshell32 -lole32 -loleaut32 -lnetapi32 -luuid -lws2_32 -lmpr -lwinmm -lve
rsion -lodbc32 -lodbccp32 -lcomctl32 -lmsvcrt
    perllibs= -lmoldname -lkernel32 -luser32 -lgdi32 -lwinspool -lcomdlg32 -ladvapi32 -lshell32 -lole32 -loleaut32 -lnetapi32 -luuid -lws2_32 -lmpr -lwinmm
-lversion -lodbc32 -lodbccp32 -lcomctl32 -lmsvcrt
    libc=-lmsvcrt, so=dll, useshrplib=true, libperl=libperl512.a
    gnulibc_version=''
  Dynamic Linking:
    dlsrc=dl_win32.xs, dlext=dll, d_dlsymun=undef, ccdlflags=' '
    cccdlflags=' ', lddlflags='-s -mdll -L"C:\Perl64\lib\CORE"'


Characteristics of this binary (from libperl):
  Compile-time options: MULTIPLICITY PERL_DONT_CREATE_GVSV
                        PERL_IMPLICIT_CONTEXT PERL_IMPLICIT_SYS
                        PERL_MALLOC_WRAP PL_OP_SLAB_ALLOC USE_64_BIT_INT
                        USE_ITHREADS USE_LARGE_FILES USE_PERLIO USE_PERL_ATOF
                        USE_SITECUSTOMIZE
  Locally applied patches:
        ActivePerl Build 1203 [294165]
        1fd8fa4 Add Wolfram Humann to AUTHORS
        f120055 make string-append on win32 100 times faster
        a2a8d15 Define _USE_32BIT_TIME_T for VC6 and VC7
        007cfe1 Don't pretend to support really old VC++ compilers
        6d8f7c9 Get rid of obsolete PerlCRT.dll support
        d956618 Make Term::ReadLine::findConsole fall back to STDIN if /dev/tty can't be opened
        321e50c Escape patch strings before embedding them in patchlevel.h
  Built under MSWin32
  Compiled at Dec  9 2010 00:50:22
  %ENV:
    PERL5OPT="-MConfig_w64"
  @INC:
    C:/Perl64/site/lib
    C:/Perl64/lib
    .


The file " C:\Perl64\site\lib\PAR \ Packer .pm" has
our $VERSION = '1.010';

Actually my previous version of Par::Packer is 1.008 and showed this problem so I updated it to 1.010 and hope this problem will go away but seems it is not.
(Also if we do not use parallel loop the packed code run fine.)

Thank you.

Frank


-----Original Message-----
From: Roderich Schupp via RT [mailto:[email protected]] 
Sent: Wednesday, July 27, 2011 6:04 PM
To: Wang, Frank
Subject: [rt.cpan.org #69848] pp created exe crash if useing parallel loops 

<URL: https://rt.cpan.org/Ticket/Display.html?id=69848 >

On 2011-07-27 17:41:15, [email protected] wrote:
> When using pp to create a stanalone executable in activeperl for x64, 
> if the source code used Parallel::Loops, the executable will crash and 
> the following is the problem detail:

This information is useless.

Please provide a minimal code example that exhibits the problem.
Also include the output of "perl -V" and the versions of PAR and PAR::Packer used.

> But the perl code itself works without any problem.

By that you mean: the code works when not packed?

Cheers, Roderich


______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email ______________________________________________________________________

______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
______________________________________________________________________

On 2011-07-28 09:43:16, [email protected] wrote:
> The following is a minimal code example that exhibits the problem:

Thanks. The good news is that I can easily reproduce the
problem here (with e.g. ActiveState 5.10.1 on 32-bit Windows XP).
The bad news is that I have no clue what's going on.

Looks like the problem occurs in some END block or in the
global destruction phase. Note that a packed executable actually
runs in a custom Perl interpreter which might have some
problem with the fork emulation on Windows.
I keep looking into this, but don't hold your breadth.

Cheers, Roderich





> 
> #!/usr/bin/perl
> use strict;
> use warnings;
> use diagnostics;
> $|=1;
> my $workers=@ARGV ? shift : 16;
> use Parallel::Loops;
> my @modelfiles=("ct_125_gulfstream_ws_26119a.txt");
> my $pl = Parallel::Loops->new($workers);
> $pl->foreach(\@modelfiles,
> sub {
>   my $mf = $_;
>   print $mf;
> }
> );
> 
> And this is the output of perl-V:
> 
> Set up gcc environment - 4.4.5 20101001 (release) [svn/rev.164871 -
> mingw-w64/oz]
> Summary of my perl5 (revision 5 version 12 subversion 2)
> configuration:
> 
>   Platform:
>     osname=MSWin32, osvers=5.2, archname=MSWin32-x64-multi-thread
>     uname=''
>     config_args='undef'
>     hint=recommended, useposix=true, d_sigaction=undef
>     useithreads=define, usemultiplicity=define
>     useperlio=define, d_sfio=undef, uselargefiles=define,
> usesocks=undef
>     use64bitint=define, use64bitall=undef, uselongdouble=undef
>     usemymalloc=n, bincompat5005=undef
>   Compiler:
>     cc='gcc', ccflags =' -DNDEBUG -O2 -DWIN32 -D_CONSOLE -DNO_STRICT
> -DHAVE_DES_FCRYPT -DCONSERVATIVE -DUSE_SITECUSTOMIZE
> -DPRIVLIB_LAST_IN_INC -DPERL_IMPLI
> CIT_CONTEXT -DPERL_IMPLICIT_SYS -DUSE_PERLIO -DPERL_MSVCRT_READFIX
> -DWIN64',
>     optimize='-O2',
>     cppflags='-DWIN32'
>     ccversion='', gccversion='4.4.5 20101001 (release) [svn/rev.164871
> - mingw-w64/oz]', gccosandvers=''
>     intsize=4, longsize=4, ptrsize=8, doublesize=8, byteorder=12345678
>     d_longlong=undef, longlongsize=8, d_longdbl=define, longdblsize=8
>     ivtype='__int64', ivsize=8, nvtype='double', nvsize=8,
> Off_t='__int64', lseeksize=8
>     alignbytes=8, prototype=define
>   Linker and Libraries:
>     ld='g++', ldflags ='-s -L"C:\Perl64\lib\CORE"'
>     libpth="C:\mingw64\lib" "C:\mingw64\x86_64-w64-mingw32\lib"
>     libs= -lmoldname -lkernel32 -luser32 -lgdi32 -lwinspool -lcomdlg32
> -ladvapi32 -lshell32 -lole32 -loleaut32 -lnetapi32 -luuid -lws2_32
> -lmpr -lwinmm -lve
> rsion -lodbc32 -lodbccp32 -lcomctl32 -lmsvcrt
>     perllibs= -lmoldname -lkernel32 -luser32 -lgdi32 -lwinspool
> -lcomdlg32 -ladvapi32 -lshell32 -lole32 -loleaut32 -lnetapi32 -luuid
> -lws2_32 -lmpr -lwinmm
> -lversion -lodbc32 -lodbccp32 -lcomctl32 -lmsvcrt
>     libc=-lmsvcrt, so=dll, useshrplib=true, libperl=libperl512.a
>     gnulibc_version=''
>   Dynamic Linking:
>     dlsrc=dl_win32.xs, dlext=dll, d_dlsymun=undef, ccdlflags=' '
>     cccdlflags=' ', lddlflags='-s -mdll -L"C:\Perl64\lib\CORE"'
> 
> 
> Characteristics of this binary (from libperl):
>   Compile-time options: MULTIPLICITY PERL_DONT_CREATE_GVSV
>                         PERL_IMPLICIT_CONTEXT PERL_IMPLICIT_SYS
>                         PERL_MALLOC_WRAP PL_OP_SLAB_ALLOC
> USE_64_BIT_INT
>                         USE_ITHREADS USE_LARGE_FILES USE_PERLIO
> USE_PERL_ATOF
>                         USE_SITECUSTOMIZE
>   Locally applied patches:
>         ActivePerl Build 1203 [294165]
>         1fd8fa4 Add Wolfram Humann to AUTHORS
>         f120055 make string-append on win32 100 times faster
>         a2a8d15 Define _USE_32BIT_TIME_T for VC6 and VC7
>         007cfe1 Don't pretend to support really old VC++ compilers
>         6d8f7c9 Get rid of obsolete PerlCRT.dll support
>         d956618 Make Term::ReadLine::findConsole fall back to STDIN if
> /dev/tty can't be opened
>         321e50c Escape patch strings before embedding them in
> patchlevel.h
>   Built under MSWin32
>   Compiled at Dec  9 2010 00:50:22
>   %ENV:
>     PERL5OPT="-MConfig_w64"
>   @INC:
>     C:/Perl64/site/lib
>     C:/Perl64/lib
>     .
> 
> 
> The file " C:\Perl64\site\lib\PAR \ Packer .pm" has
> our $VERSION = '1.010';
> 
> Actually my previous version of Par::Packer is 1.008 and showed this
> problem so I updated it to 1.010 and hope this problem will go away
> but seems it is not.
> (Also if we do not use parallel loop the packed code run fine.)
> 
> Thank you.
> 
> Frank
> 
> 
> -----Original Message-----
> From: Roderich Schupp via RT [mailto:[email protected]]
> Sent: Wednesday, July 27, 2011 6:04 PM
> To: Wang, Frank
> Subject: [rt.cpan.org #69848] pp created exe crash if useing parallel
> loops
> 
> <URL: https://rt.cpan.org/Ticket/Display.html?id=69848 >
> 
> On 2011-07-27 17:41:15, [email protected] wrote:
> > When using pp to create a stanalone executable in activeperl for
> x64,
> > if the source code used Parallel::Loops, the executable will crash
> and
> > the following is the problem detail:
> 
> This information is useless.
> 
> Please provide a minimal code example that exhibits the problem.
> Also include the output of "perl -V" and the versions of PAR and
> PAR::Packer used.
> 
> > But the perl code itself works without any problem.
> 
> By that you mean: the code works when not packed?
> 
> Cheers, Roderich
> 
> 
> ______________________________________________________________________
> This email has been scanned by the MessageLabs Email Security System.
> For more information please visit http://www.messagelabs.com/email
> ______________________________________________________________________
> 
> ______________________________________________________________________
> This email has been scanned by the MessageLabs Email Security System.
> For more information please visit http://www.messagelabs.com/email
> ______________________________________________________________________

On 2011-08-01 10:26:13, RSCHUPP wrote:
> I keep looking into this, 

The actual problem is that a packed script actually runs inside
a BEGIN block. If you simply put everything in your example script
(except the "use" statements) into a BEGIN block, then it
will blow up even unpacked.

The perlfork man page explicitly states that fork (i.e. the
emulation for Windows) might fail when invoked inside BEGIN.

As to why PAR::Packer wraps a packed script into a BEGIN block:
I don't know - it has always been the case (according to the
history in Subversion). 

Cheers, Roderich

Hi Rodrich,

Thank you for inform me of this finding. Just wondering maybe it is possible to 
update PAR::Packer soon since wrap packed script into a BEGIN block or into BODY 
block seems do not need much change? and the pack function and parallel process 
function are very desirable feature of Perl.

Regards,

Frank



-----Original Message-----
From: Roderich Schupp via RT [mailto:[email protected]] 
Sent: Tuesday, August 02, 2011 5:26 AM
To: Wang, Frank
Subject: [rt.cpan.org #69848] pp created exe crash if useing parallel loops 

<URL: https://rt.cpan.org/Ticket/Display.html?id=69848 >

On 2011-08-01 10:26:13, RSCHUPP wrote:
> I keep looking into this, 

The actual problem is that a packed script actually runs inside
a BEGIN block. If you simply put everything in your example script
(except the "use" statements) into a BEGIN block, then it
will blow up even unpacked.

The perlfork man page explicitly states that fork (i.e. the
emulation for Windows) might fail when invoked inside BEGIN.

As to why PAR::Packer wraps a packed script into a BEGIN block:
I don't know - it has always been the case (according to the
history in Subversion). 

Cheers, Roderich

______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
______________________________________________________________________

______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
______________________________________________________________________

On 2011-08-02 17:55:58, [email protected] wrote:
> Just wondering maybe it is possible to
> update PAR::Packer soon since wrap packed script into a BEGIN block or
> into BODY block seems do not need much change?

Sorry, unlikely soon. There has to be a reason why practically all
of script/par.pl (which eventually calls "do 'your_original_script'")
is wrapped in BEGIN (and eval {} to boot), but I don't know it
(mind you, I'm not the original author). Any change in this crucial
piece of the PAR::Packer machinery needs consideration and
extensive testing for which I don't have time ATM.

Cheers, Roderich

On 2011-08-03 02:38:43, RSCHUPP wrote:
> piece of the PAR::Packer machinery needs consideration and
> extensive testing for which I don't have time ATM.

Just as a reminder to myself...
Things done to narrow down the problem - but still no solution:

- reduced the span of the BEGIN block in script/par.pl
- verified that the packed script is NOT executed from "inside"
  BEGIN or eval() any more
- set PL_perl_destruct_level=1 in myldr/main.c for perl_construct()
  and perl_destruct() call (but to no avail)
- problem occurs definitely AFTER the end of normal execution
  (but still in perl_run())
- using Devel::Symdump we see that the only END blocks registered
  are in File::Temp, PAR and par.pl 
- by instrumenting these END blocks we see that the problem 
  occurs AFTER they have been run
- the problem is not specific to Parallel::Loops or
  Parallel::ForkManager, the following script shows the same
  symptoms (with or without the wait()ing at the end)

use strict;
use warnings;
for (1..5)
{
    my $pid = fork();
    die "fork failed: $!" unless defined $pid;

    if ($pid == 0)
    {
        # child
        print STDERR "child $$\n";
        exit(0);
    }
}
print STDERR "waiting for children ...\n";
while ((my $pid = wait()) != -1)
{
    print STDERR "reaped $pid\n";
}

On 2020-04-22 08:13:31, [email protected] wrote:
>     La gestion des fork ne fonctionne pas, fin prématuré de l'exe suivit
>     egalement des erreurs Windows

What's the error message?

Try replacing the wait call with waitpid.
Note: the Windows version of PAR::Packer is special: the custom Perl interpreter
runs as (spawned) child of the bootstrap process, while on *nix Perl is
exec'ed by bootstrap.

Cheers, Roderich

Le 22/04/2020 à 15:14, Roderich Schupp via RT a écrit :
> <URL: https://rt.cpan.org/Ticket/Display.html?id=132398 >
>
> On 2020-04-22 08:13:31, [email protected] wrote:
>>      La gestion des fork ne fonctionne pas, fin prématuré de l'exe suivit
>>      egalement des erreurs Windows
> What's the error message?
>
> Try replacing the wait call with waitpid.
> Note: the Windows version of PAR::Packer is special: the custom Perl interpreter
> runs as (spawned) child of the bootstrap process, while on *nix Perl is
> exec'ed by bootstrap.
>
> Cheers, Roderich

Changement de la source en :

>     use strict;
>     use warnings;
>     use diagnostics;
>     use 5.010;
>
>     my $name = 'Foo';
>
>     say "PID $$";
>     my $pid = fork();
>     die if not defined $pid;
>     if (not $pid) {
>        say "In child  ($name) - PID $$ ($pid)";
>        $name = 'Qux';
>         sleep 2;
>        say "In child  ($name) - PID $$ ($pid)";
>        exit;
>     }
>
>     say "In parent ($name) - PID $$ ($pid)";
>     $name = 'Bar';
>      sleep 2;
>     say "In parent ($name) - PID $$ ($pid)";
>
>     #my $finished = wait();
>     my $finished = waitpid -1, 0;
>     say "In parent ($name) - PID $$ finished $finished";

C'est la même chose, se termine avant d�exécuter la ligne

    "say "In parent ($name) - PID $$ finished $finished";"

sans message d'erreur

On 2020-04-22 11:22:03, [email protected] wrote:
> > my $finished = waitpid -1, 0;

What about

my $finished = waitpid($pid, 0);

Please switch to English.

Cheers, Roderich

Le 22/04/2020 à 17:49, Roderich Schupp via RT a écrit :
> <URL: https://rt.cpan.org/Ticket/Display.html?id=132398 >
>
> On 2020-04-22 11:22:03, [email protected] wrote:
>>> my $finished = waitpid -1, 0;
> What about
>
> my $finished = waitpid($pid, 0);
>
> Please switch to English.
>
> Cheers, Roderich

The modification gives the same thing the executable ends prematurely

Le 22/04/2020 à 17:49, Roderich Schupp via RT a écrit :
> <URL: https://rt.cpan.org/Ticket/Display.html?id=132398 >
>
> On 2020-04-22 11:22:03, [email protected] wrote:
>>> my $finished = waitpid -1, 0;
> What about
>
> my $finished = waitpid($pid, 0);
>
> Please switch to English.
>
> Cheers, Roderich


is there a way to use PAR :: Packer with a module using fork like poe :: 
wheel :: run or Parallel :: ForkManager or simply by using the perl fork 
command. Or pierce another way to compile a perl script in exe Thank you 
for your help.

On 2020-04-23 12:09:26, [email protected] wrote:
> is there a way to use PAR :: Packer with a module using fork like poe :: 
> wheel :: run or Parallel :: ForkManager or simply by using the perl fork 
> command. 

Dunno. The difference in behaviour of your sample script in "normal"
and pp'ed versions is definitively a bug, but I have no means
(i.e. no Windows) to investigate it. In any case, fork and wait* on
Windows is a minefield.

You might also ask for help on the PAR mailing list, [email protected]
(no registration required).

> Or pierce another way to compile a perl script in exe

What do you mean by "compile a perl script in exe"?

Cheeers, Roderich

diff --git a/myldr/find_files_to_embed/guess.pl b/myldr/find_files_to_embed/guess.pl
index a86995b..45d28c1 100644
--- a/myldr/find_files_to_embed/guess.pl
+++ b/myldr/find_files_to_embed/guess.pl
@@ -20,7 +20,7 @@ sub find_files_to_embed
     # in the same way as libperl*.dll itself, otherwise a packed executable
     # won't run when libgcc_*.dll isn't installed.
     # The same holds for libstdc++*.dll (e.g. Strawberry Perl 5.16).
-    my ($libgcc, $libstdcpp, $libwinpthread);
+    my ($libgcc, $libstdcpp, $libwinpthread, @msvclibs);
     if ($^O eq 'MSWin32'
         and defined $Config{gccversion}             # gcc version >= 4.x was used
         and $Config{gccversion} =~ m{\A(\d+)}ms && $1 >= 4) {
@@ -30,9 +30,21 @@ sub find_files_to_embed
     if ($ld =~ /(\b|-)g\+\+(-.*)?(\.exe)?$/) {      # g++ was used to link
         $libstdcpp = find_dll("libstdc++*.$Config{so}");
     }
+    if ($ld eq 'link') {      # link was used to link, probably using MSVC, add the VCRUNTIME
+        print STDERR "ld is [$ld], finding VCRUNTIME DLLs\n";
+        for my $dll ( qw( concrt140
+            msvcp140
+            vcruntime140
+            vcruntime140_1 ) ) {
+
+            push @msvclibs, find_dll("$dll*.$Config{so}");
+        }
+        print STDERR "Found MSVC DLLs: ", join(', ', @msvclibs ), "\n";
+    }
+

     return { map { basename($_) => $_ }
-                 grep { defined } $libperl, $libgcc, $libwinpthread, $libstdcpp };
+                 grep { defined } $libperl, $libgcc, $libwinpthread, $libstdcpp, @msvclibs };
 }

#!/usr/bin/env perl

use strict;
use warnings;

print "Hello, World!\n";

perl -Iextlib-MSWin32-x64-multi-thread\lib\perl5 extlib-MSWin32-x64-multi-thread\bin\pp -o hello.exe hello.pl

Z:\par-packer-testing>"C:\Program Files (x86)\Microsoft Visual Studio\2019\BuildTools\VC\Tools\MSVC\14.28.29333\bin\Hostx64\x64\dumpbin.exe" /DEPENDENTS hello.exe
Microsoft (R) COFF/PE Dumper Version 14.28.29334.0
Copyright (C) Microsoft Corporation.  All rights reserved.


Dump of file hello.exe

File Type: EXECUTABLE IMAGE

  Image has the following dependencies:

    KERNEL32.dll
    ADVAPI32.dll
    VCRUNTIME140.dll
    api-ms-win-crt-runtime-l1-1-0.dll
    api-ms-win-crt-string-l1-1-0.dll
    api-ms-win-crt-filesystem-l1-1-0.dll
    api-ms-win-crt-stdio-l1-1-0.dll
    api-ms-win-crt-environment-l1-1-0.dll
    api-ms-win-crt-heap-l1-1-0.dll
    api-ms-win-crt-process-l1-1-0.dll
    api-ms-win-crt-math-l1-1-0.dll
    api-ms-win-crt-locale-l1-1-0.dll

  Summary

      3E1000 .data
        1000 .pdata
        2000 .rdata
        1000 .reloc
        3000 .rsrc
        4000 .text

Z:\par-packer-testing>"C:\Program Files (x86)\Microsoft Visual Studio\2019\BuildTools\VC\Tools\MSVC\14.28.29333\bin\Hostx64\x64\dumpbin.exe" /DEPENDENTS hello-sp.exe
Microsoft (R) COFF/PE Dumper Version 14.28.29334.0
Copyright (C) Microsoft Corporation.  All rights reserved.


Dump of file hello-sp.exe

File Type: EXECUTABLE IMAGE

  Image has the following dependencies:

    msvcrt.dll
    ADVAPI32.dll
    KERNEL32.dll

  Summary

        1000 .CRT
        A000 .bss
      4D4000 .data
        1000 .idata
        1000 .pdata
        1000 .rdata
        3000 .rsrc
        A000 .text
        1000 .tls
        1000 .xdata

@echo off
setlocal

if exist "compiled.exe" del "compiled.exe"
echo Compiling
pp -o compiled.exe source.pl
if exist "compiled.exe" echo Success
if not exist "compiled.exe" echo Failed

@echo off
setlocal

if exist "compiled.exe" del "compiled.exe"
echo Compiling
start "Compiling" /d"%cd%" /wait pp -o compiled.exe source.pl
if exist "compiled.exe" echo Success
if not exist "compiled.exe" echo Failed

"/usr/perlbrew/perls/perl-5.28.2/bin/perl" -Mblib=.. run_with_inc.pl ./par -q -B -Oparldyn
Can't locate Digest/SHA.pm in @INC (you may need to install the Digest::SHA module) (@INC contains: /mnt/hgfs/projects/pcore-lib/pcore/lib /tmp/.cpanm/work/1556682277.52386/PAR-Packer-1.048/lib/site_perl/5.28.2/x86_64-linux-ld /tmp/.cpanm/work/1556682277.52386/PAR-Packer-1.048/lib/site_perl/5.28.2 /tmp/.cpanm/work/1556682277.52386/PAR-Packer-1.048/lib/5.28.2/x86_64-linux-ld /tmp/.cpanm/work/1556682277.52386/PAR-Packer-1.048/lib/5.28.2 .) at -e line 474.
system(./par -I../blib/arch -I../blib/lib -I/mnt/hgfs/projects/pcore-lib/pcore/lib -I/usr/perlbrew/perls/perl-5.28.2/lib/site_perl/5.28.2/x86_64-linux-ld -I/usr/perlbrew/perls/perl-5.28.2/lib/site_perl/5.28.2 -I/usr/perlbrew/perls/perl-5.28.2/lib/5.28.2/x86_64-linux-ld -I/usr/perlbrew/perls/perl-5.28.2/lib/5.28.2 -I. -q -B -Oparldyn) failed:
make[1]: *** [Makefile:908: parldyn] Error 2
make[1]: Leaving directory '/tmp/.cpanm/work/1556682277.52386/PAR-Packer-1.048/myldr'
make: *** [Makefile:542: subdirs] Error 2
FAIL
! Installing R/RS/RSCHUPP/PAR-Packer-1.048.tar.gz failed. See /tmp/.cpanm/work/1556682277.52386/build.log for details. Retry with --force to force install it.

pp
Windows 10 , Strawberry perl 5.26
PAR Packager, version 1.047 (PAR version 1.015)

---------  perl code --

use strict;
use warnings;
foreach (<DATA>) {
 print "data: $_ \n";
 }
 1;

 __END__
 __DATA__
 This is line one
 This is line two

------- end ------
--- command line  ----
C:\perlutils\Perl64\perl\site\bin\pp -c -F Bleach -f Bleach -o pp-flter-err-demo.exe pp-filter-error-demo.pm

--- end ----

--Results ---
pp-flter-err-demo.exe
readline() on unopened filehandle DATA at (eval 13) line 3.

---end ---

Filter::Crypto has same results. No filter is fine.

Thanks.
Don


Don Peddicord
SPAWAR Systems Center Atlantic
[email protected]<mailto:[email protected]>
843-218-6901

On 2018-10-31 12:51:13, [email protected] wrote:
> ---------  perl code --

Hi Don,

I checked how PAR::Filter::Bleach transforms you script when it gets
packed and the resulting file looks OK (esp. __DATA__ hasn't been stripped).
The problem appears to be caused by Perl itself. 
Try the following script (this is essentially how PAR::Filter::Bleach works):

----- snip -----
$_=<<'...'; print "---\n$_---\n"; eval $_;
use strict;
use warnings;
print "DATA start\n";
foreach (<DATA>) {
 print "data: $_ \n";
}
print "DATA end\n";
1;

__DATA__
This is line one
This is line two
...
----- snip -----

Running this I get:


---
use strict;
use warnings;
print "DATA start\n";
foreach (<DATA>) {
 print "data: $_ \n";
}
print "DATA end\n";
1;

__DATA__
This is line one
This is line two
---
DATA start
readline() on unopened filehandle DATA at (eval 1) line 4.
DATA end


So "eval STRING;" somehow ignores __DATA__ content in STRING.
PAR::Filter::Crypto is implemented differently: it's a source filter
(cf. "perldoc perlfilter", esp. "THINGS TO LOOK OUT FOR"), 
but source filters also interact badly with __DATA__:

----- snip -----
use Filter::exec qw( cat );
use strict;
use warnings;
print "DATA start\n";
foreach (<DATA>) {
 print "data: $_ \n";
}
print "DATA end\n";
1;

__DATA__
This is line one
This is line two
----- snip -----

Running it produces:

DATA start
DATA end


So, in short, packing scripts that use __DATA__ with-f/-F won't work
and there's nothing PAR::Packer can do about it.

Cheers, Roderich

SHA.c: loadable library and perl binaries are mismatched (got handshake key 0000000000028fa8, needed 0000000000000000)

test.pl:

use TestModule;

TestModule.pm:

print __FILE__, "\n";

pp -o test test.pl; ./test

TestModule.pm

env PAR_VERBATIM=1 pp -o test test.pl; ./test

/tmp/par-6772696e6e7a/cache-3389c9f99dff4f9a1680ee679c53debbe9e2e918/inc/lib/TestModule.pm

The filename override causes __FILE__ to then be unusable within the module since TestModule.pm is not found within cwd.

I wonder why this filter overrides the filename at all. It should be able to set line numbers and omit the filename.

On 2020-03-04 18:57:24, DBOOK wrote:
> The filename override causes __FILE__ to then be unusable within the
> module since TestModule.pm is not found within cwd.

Don't do that then.

And yes, there are modules that behave differently when run from a packed executable.
PAR/Filter/PatchContent.pm contains workarounds for the known ones.

> I wonder why this filter overrides the filename at all. It should be
> able to set line numbers and omit the filename.

My guess is that the filename is for the benefit of the "embedded files"
(cf. https://metacpan.org/pod/distribution/PAR/lib/PAR/Tutorial.pod#Anatomy-of-a-Self-Contained-PAR-executable) 
as these are extracted with mangled names like "776cb274.pm". Hence any runtime 
diagnostic messages originating from one of these modules would be pretty useless.

Cheers, Roderich

On Thu Mar 05 03:31:08 2020, RSCHUPP wrote:
> On 2020-03-04 18:57:24, DBOOK wrote:
> > The filename override causes __FILE__ to then be unusable within the
> > module since TestModule.pm is not found within cwd.
> 
> Don't do that then.
> 
> And yes, there are modules that behave differently when run from a
> packed executable.
> PAR/Filter/PatchContent.pm contains workarounds for the known ones.

FWIW, the distribution that ran into this problem is Mojolicious. It uses the path to modules to find its bundled resource files in several places.

-Dan

On Thu Mar 05 11:22:46 2020, DBOOK wrote:
> On Thu Mar 05 03:31:08 2020, RSCHUPP wrote:
> > On 2020-03-04 18:57:24, DBOOK wrote:
> > > The filename override causes __FILE__ to then be unusable within
> > > the
> > > module since TestModule.pm is not found within cwd.
> >
> > Don't do that then.
> >
> > And yes, there are modules that behave differently when run from a
> > packed executable.
> > PAR/Filter/PatchContent.pm contains workarounds for the known ones.
> 
> FWIW, the distribution that ran into this problem is Mojolicious. It
> uses the path to modules to find its bundled resource files in several
> places.
> 
> -Dan

And I will additionally note, this works perfectly fine as long as PodStrip is not run.

-Dan

On 2020-03-05 08:22:46, DBOOK wrote:

> FWIW, the distribution that ran into this problem is Mojolicious. It
> uses the path to modules to find its bundled resource files in several
> places.

Would File::ShareDir work any better here, I wonder?

On 2020-03-06 00:07:28, ETHER wrote:
> On 2020-03-05 08:22:46, DBOOK wrote:
> 
> > FWIW, the distribution that ran into this problem is Mojolicious. It
> > uses the path to modules to find its bundled resource files in several
> > places.
> 
> Would File::ShareDir work any better here, I wonder?

That was my thought, too. 

Note that using __FILE__ at runtime isn't the only problem here.
The bundled resource files need special treatment when packing a script:
Module::ScanDeps doesn't detect them automagically so they won't get packed.

Cheers, Roderich

On 2020-03-05 11:22:46, DBOOK wrote:
> On Thu Mar 05 03:31:08 2020, RSCHUPP wrote:
> FWIW, the distribution that ran into this problem is Mojolicious. It
> uses the path to modules to find its bundled resource files in several
> places.

The explicit use of __FILE__ in Mojo::Util is easily fixed.
The implicit use via "(caller)[1]" in Mojo::File is a bit trickier.

Does the attched patch help?

Cheers, Roderich

sub nonesuch {
    return 1;
}

pp -x -e "use Path::Tiny; my $fname = Path::Tiny::path (q{./file_to_do.pl})->absolute; do $fname; my ($key) = grep {$_ =~ /file_to_do.pl/} keys %INC; print qq{$key listed at $INC{$key}\n}"

C:/Users/user/file_to_do.pl listed at C:/Users/user/file_to_do.pl

a.exe

mkdir C:\Users\user\AppData\Local\Temp\par-736861776e\cache-698cac0bf5bb21686699b7df22397f891e18d751\inc\lib\C:\: Invalid argument; The filename, directory name, or volume label syntax is incorrect at C:/berrybrew/5.26.1_64_PDL/perl/vendor/lib/Archive/Zip/Archive.pm line 195.

$ cpan -i -f PAR::Packer
Loading internal logger. Log::Log4perl recommended for better logging
Reading '/Users/myuser/.cpan/Metadata'
  Database was generated on Wed, 14 Aug 2019 22:55:26 GMT
Running install for module 'PAR::Packer'
CPAN: Digest::SHA loaded ok (v5.95)
CPAN: Compress::Zlib loaded ok (v2.068)
Checksum for /Users/myuser/.cpan/sources/authors/id/R/RS/RSCHUPP/PAR-Packer-1.049.tar.gz ok
CPAN: YAML loaded ok (v1.15)
CPAN: CPAN::Meta::Requirements loaded ok (v2.133)
CPAN: Parse::CPAN::Meta loaded ok (v1.4417)
CPAN: CPAN::Meta loaded ok (v2.150005)
CPAN: Module::CoreList loaded ok (v5.20160320)
Configuring R/RS/RSCHUPP/PAR-Packer-1.049.tar.gz with Makefile.PL
ld: library not found for -lgcc_s.10.4
clang: error: linker command failed with exit code 1 (use -v to see invocation)
No compiler found, won't generate 'script/parl!
Checking if your kit is complete...
Looks good
Generating a Unix-style Makefile
Writing Makefile for PAR::Packer
Writing MYMETA.yml and MYMETA.json
  RSCHUPP/PAR-Packer-1.049.tar.gz
  /usr/local/bin/perl Makefile.PL -- OK
Running make for R/RS/RSCHUPP/PAR-Packer-1.049.tar.gz
cp lib/App/Packer/PAR.pm blib/lib/App/Packer/PAR.pm
cp lib/PAR/Packer.pm blib/lib/PAR/Packer.pm
cp lib/PAR/Filter.pm blib/lib/PAR/Filter.pm
cp lib/PAR/Filter/Obfuscate.pm blib/lib/PAR/Filter/Obfuscate.pm
cp lib/PAR/Filter/Bleach.pm blib/lib/PAR/Filter/Bleach.pm
cp lib/PAR/Filter/PatchContent.pm blib/lib/PAR/Filter/PatchContent.pm
cp lib/PAR/Filter/PodStrip.pm blib/lib/PAR/Filter/PodStrip.pm
cp lib/PAR/Filter/Bytecode.pm blib/lib/PAR/Filter/Bytecode.pm
cp lib/pp.pm blib/lib/pp.pm
cp lib/PAR/StrippedPARL/Base.pm blib/lib/PAR/StrippedPARL/Base.pm
cp script/tkpp blib/script/tkpp
"/usr/local/bin/perl" -MExtUtils::MY -e 'MY->fixin(shift)' -- blib/script/tkpp
cp script/par.pl blib/script/par.pl
"/usr/local/bin/perl" -MExtUtils::MY -e 'MY->fixin(shift)' -- blib/script/par.pl
cp script/pp blib/script/pp
"/usr/local/bin/perl" -MExtUtils::MY -e 'MY->fixin(shift)' -- blib/script/pp
Manifying 3 pod documents
Manifying 10 pod documents
  RSCHUPP/PAR-Packer-1.049.tar.gz
  /usr/bin/make -- OK
CPAN: CPAN::DistnameInfo loaded ok (v0.12)
Running make test for RSCHUPP/PAR-Packer-1.049.tar.gz
PERL_DL_NONLAZY=1 "/usr/local/bin/perl" "-MExtUtils::Command::MM" "-MTest::Harness" "-e" "undef *Test::Harness::Switches; test_harness(0, 'blib/lib', 'blib/arch')" t/*.t
t/00-pod.t ............... skipped: Set environment variable PERL_TEST_POD=1 to test POD
t/10-parl-generation.t ... 1/31 
#   Failed test 'Found the static build of parl in myldr'
#   at t/10-parl-generation.t line 28.
# Looks like you failed 1 test of 31.
t/10-parl-generation.t ... Dubious, test returned 1 (wstat 256, 0x100)
Failed 1/31 subtests 
	(less 27 skipped subtests: 3 okay)
t/20-pp.t ................ skipped: 'parl' not found
t/30-current_exec.t ...... # Please wait
t/30-current_exec.t ...... ok   
t/40-packer_cd_option.t .. ok   
t/80-doublecolon.t ....... ok   
t/85-crt-glob.t .......... ok   
t/90-rt101800.t .......... 1/18 # PAR_TEMP = /var/folders/rv/spd1m5_524j35pnylts_bxvm0000gn/T/ce7aimSWJO/par-64616e69656c6361737069/cache-4796669d20cf6c8138fcf3569ea592a4929c3226
# running /var/folders/rv/spd1m5_524j35pnylts_bxvm0000gn/T/ce7aimSWJO/packed a second time
t/90-rt101800.t .......... 12/18 # running /var/folders/rv/spd1m5_524j35pnylts_bxvm0000gn/T/ce7aimSWJO/packed a third time
t/90-rt101800.t .......... ok     
t/90-rt103861.t .......... ok   
t/90-rt104560.t .......... ok   
t/90-rt104635.t .......... ok   
t/90-rt122949.t .......... skipped: Tests only relevant on Windows
t/90-rt127064.t .......... skipped: Tests only relevant on Windows
t/90-rt129312.t .......... 1/4 
#   Failed test 'successfully ran "/var/folders/rv/spd1m5_524j35pnylts_bxvm0000gn/T/xKDvYqUyJC/packed"'
#   at ./t/utils.pl line 39.
#          got: '65280'
#     expected: '0'

#   Failed test at t/90-rt129312.t line 23.
#          got: ''
#     expected: 'hello, garbage
# '
# stderr: Usage: /var/folders/rv/spd1m5_524j35pnylts_bxvm0000gn/T/xKDvYqUyJC/packed [ -Alib.par ] [ -Idir ] [ -Mmodule ] [ src.par ] [ program.pl ]
# /var/folders/rv/spd1m5_524j35pnylts_bxvm0000gn/T/xKDvYqUyJC/packed [ -B|-b ] [-Ooutfile] src.par
# Looks like you failed 2 tests of 4.
t/90-rt129312.t .......... Dubious, test returned 2 (wstat 512, 0x200)
Failed 2/4 subtests 
t/90-rt59710.t ........... ok   

Test Summary Report
-------------------
t/10-parl-generation.t (Wstat: 256 Tests: 31 Failed: 1)
  Failed test:  4
  Non-zero exit status: 1
t/90-rt129312.t        (Wstat: 512 Tests: 4 Failed: 2)
  Failed tests:  3-4
  Non-zero exit status: 2
Files=15, Tests=83, 16 wallclock secs ( 0.05 usr  0.03 sys +  7.35 cusr  2.24 csys =  9.67 CPU)
Result: FAIL
Failed 2/15 test programs. 3/83 subtests failed.
make: *** [test_dynamic] Error 255
  RSCHUPP/PAR-Packer-1.049.tar.gz
  /usr/bin/make test -- NOT OK
//hint// to see the cpan-testers results for installing this module, try:
  reports RSCHUPP/PAR-Packer-1.049.tar.gz
Running make install for RSCHUPP/PAR-Packer-1.049.tar.gz
Manifying 3 pod documents
Manifying 10 pod documents
Installing /usr/local/lib/perl5/site_perl/5.18.2/pp.pm
Installing /usr/local/lib/perl5/site_perl/5.18.2/PAR/Packer.pm
Installing /usr/local/share/man/man1/tkpp.1
Installing /usr/local/share/man/man1/par.pl.1
Installing /usr/local/share/man/man3/PAR::StrippedPARL::Base.3
Installing /usr/local/share/man/man3/PAR::Packer.3
Installing /usr/local/share/man/man3/PAR::Filter::PatchContent.3
Installing /usr/local/share/man/man3/pp.3
Installing /usr/local/share/man/man3/PAR::Filter::Bytecode.3
Installing /usr/local/share/man/man3/PAR::Filter::PodStrip.3
Installing /usr/local/share/man/man3/PAR::Filter::Bleach.3
Installing /usr/local/share/man/man3/PAR::Filter::Obfuscate.3
Installing /usr/local/share/man/man3/PAR::Filter.3
Installing /usr/local/share/man/man3/App::Packer::PAR.3
Installing /usr/local/bin/par.pl
Appending installation info to /usr/local/lib/perl5/5.18.2/darwin-2level/perllocal.pod
  RSCHUPP/PAR-Packer-1.049.tar.gz
  /usr/bin/make install  -- OK

[root@localhost html]# rpm -q centos-release
centos-release-7-9.2009.1.el7.centos.x86_64

[root@localhost html]# httpd -v
Server version: Apache/2.4.6 (CentOS)
Server built:   Dec 13 2020 00:35:05

[root@localhost html]# perl -v
This is perl 5, version 34, subversion 0 (v5.34.0) built for x86_64-linux

[root@localhost html]# cpan
cpan shell -- CPAN exploration and modules installation (v2.28)

[root@localhost html]# pwd
/var/www/html

[root@localhost html]# ls -lha
-rw-r--r--. 1 apache apache  239 Jul 26 09:54 .htaccess
-rw-r--r--. 1 apache apache   47 Jul 25 20:00 index.html
-rwxr-xr-x. 1 apache apache   97 Jul 26 11:02 perl.pl

PERL script content

#!/usr/bin/perl
use strict;
use warnings;

print "Content-type: text/html\n\n";

print "Hello World!";

exit;

[root@localhost html]# pp -x -c -o a.out perl.pl
/tmp/kjzLwQRe6G syntax OK

[root@localhost html]# mv a.out xx.pl
[root@localhost html]# chown apache:apache xx.pl
[root@localhost html]# chmod 755 xx.pl

[root@localhost html]# ./perl.pl
Content-type: text/html

Hello World![root@localhost html]# ./xx.pl
Content-type: text/html

Hello World![root@localhost html]#

[root@localhost html]# tail -f /var/log/httpd/ssl_error_log
[Mon Jul 26 11:06:18.315481 2021] [cgi:error] [pid 18880] [client 2.57.171.41:12219] End of script output before headers: xx.pl
[Mon Jul 26 11:07:21.702880 2021] [cgi:error] [pid 18881] [client 2.57.171.41:9437] End of script output before headers: xx.pl
[Mon Jul 26 11:07:22.742897 2021] [cgi:error] [pid 18879] [client 2.57.171.41:19913] End of script output before headers: xx.pl
[Mon Jul 26 11:07:28.448565 2021] [cgi:error] [pid 18882] [client 2.57.171.41:27467] End of script output before headers: xx.pl
[Mon Jul 26 11:30:08.557949 2021] [cgi:error] [pid 18883] [client 2.57.171.41:30987] End of script output before headers: xx.pl

<Directory /var/www>
     Options +ExecCGI
     SetHandler cgi-script
     AddHandler cgi-script .bin .pl .cgi
</Directory>

<Directory /var/www/mycgi-bin>
     ExecCGI Options
     SetHandler cgi-script
     AddHandler cgi-script .bin .pl .cgi
</Directory>

When building PAR::Packer with cperl (at least 5.28.2c, 5.30.0c) almost all test fail
with the same error message:

$ pp -o a.exe -E 0
panic: attempt to copy freed scalar 55c95f55e3e0 to 55c95f55dde0 at <embedded>/Tie/Hash/NamedCapture.pm line 7.
Compilation failed in require at -e line 140.

This is caused by cperl moving XSLoader from an external XSLoader.pm module directly into DynaLoader.so, hence patching XSLoader.pm via PAR::Filter::PatchContent doesn't work anymore.

As reminder to myself: looks like the following is happening:

1. pp runs (in PAR::Packer::_generate_output)
   parl -B -Oa.exe some.par

2. loads Tie/Hash/NamedCapture.pm with demangled name from the cache area

3. loads NamedCapture.so from the install location (_not_ the demangled copy from 
   the cache area though it is present) and calls boot_Tie__Hash__NamedCapture
   which panics

At that point (2) and (3) have worked successfully for lots of other "embedded" modules, 
so I dunno why Tie::Hash::NamedCapture behaves differently.
But the real problem is that dynamic loading of mangled DLLs from the cache area 
doesn't work, because intercepting dynamic loading doesn't work without the
patch to XSLoader.