rschupp / par-packer Goto Github PK
View Code? Open in Web Editor NEW(perl) Generate stand-alone executables, perl scripts and PAR files https://metacpan.org/pod/PAR::Packer
License: Other
(perl) Generate stand-alone executables, perl scripts and PAR files https://metacpan.org/pod/PAR::Packer
License: Other
Hi
Application not executed on PC without perl.
This is my incorrect actions or PAK::Parser bug ???
I created two pp binaries, one for x86_64 and one for ARM, signed them both, both work. Then combined them into a universal binary with lipo
, resulting in new binary. This only works on ARM and the x86_64 fails with errors like this:
Compilation failed in require at /loader/HASH(0x7fdba0884a10)/XSLoader.pm line 118.
Just wanted to confirm that this won't work due to the assumptions pp
'ed binaries make about headers etc. I assume that there is no way to create universal binaries with pp
?
When I run a PAR::Packer compiled CGI script directly from Powershell, it works as expected. But, when I run the same executable from IIS 10.0 (Windows Server 2019) I receive the following error:
HTTP Error 502.2 - Bad Gateway
The specified CGI application misbehaved by not returning a complete set of HTTP headers. The headers it did return are "Usage: \\?\C:\inetpub\wwwroot\parpacker_test.exe [ -Alib.par ] [ -Idir ] [ -Mmodule ] [ src.par ] [ program.pl ] \\?\C:\inetpub\wwwroot\parpacker_test.exe [ -B|-b ] [-Ooutfile] src.par ".
When I run the same script compiled instead using PerlApp in IIS 10.0, the web server responds with the Hello World!
response I'm expecting.
When running the PAR::Packer compiled script from IIS, the script is running from the IUSR
user. Only one of the par-XXX
cache directories is created with only 4 dll
s and a parpacker_test.exe
. The same user is able to run the same script using an executable created using PerlApp. I've included the test script, the non-working directory contents, and the working directory contents below.
#!/usr/bin/perl
print "Content-type:text/html\r\n\r\n";
print '<html>';
print '<head>';
print '<title>Hello</title>';
print '</head>';
print '<body>';
print '<h2>Hello World!</h2>';
print '</body>';
print '</html>';
1;
For the PAR::Packer test executable, this is compiled using just pp -o parpacker_test.exe test.pl
.
For the PerlApp test executable, I compiled using perlapp --exe perlapp_example.exe test.pl
.
C:\Windows\Temp\par-414b554c50412d44455624\
directory contents:
Mode LastWriteTime Length Name
---- ------------- ------ ----
d----- 4/1/2021 5:33 PM cache-93c4d81e1f9fc1ccb321da4d056f0d78e2a44841
cache-XXX
directories is unpacked here.C:\Windows\Temp\par-414b554c50412d44455624\cache-93c4d81e1f9fc1ccb321da4d056f0d78e2a44841
directory contents:
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
C:\Users\MyUSER\AppData\Local\Temp\2\par-616e647265772e6b756c7061
directory contents:
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
cache-522d9f0811561fc3f902af2285fca57cbad3e26d
directory contents:
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
cache-71e892043d28332eab6e4f5d98e289b6c0ece2d5
directory contents:
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
cache-93c4d81e1f9fc1ccb321da4d056f0d78e2a44841
directory contents:
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
IIS output and executable failure with 502 response code doesn't change regardless of changing any of the following:
It seems that perl 5.32, at least on Strawberry 32 and 64 bit and linux 64-bit doesnt' include utf8_heavy.pl
any more for some reason and this makes pp --unicode
die. I thought initially it was some packaging error with Strawberry but I had the same with a fresh 5.32 build on linux 64-bit. I had to copy the utf8_heavy.pl
from a 5.30 install and then it was fine ... not sure if you are aware of this.
As per this long-standing slew of issues on Windows:
https://www.nu42.com/2017/02/perl-unicode-windows-trilogy-one.html
and the fix derived from this here:
https://github.com/circulosmeos/Perl-with-Unicode-for-Windows
it's possible to patch windows perl quite easily to fix the unicode file-system and command-line argument problems. I've tested it with 64-bit Strawberry 5.32 and it is a magic bullet for all sorts of horrible unicode issues on Windows. It's the only way to really fix it, apparently. However, when I pack my app with a fixed perl.exe
, the resulting PAR exe is still broken in the usual ways, presumably because pp
doesn't really call perl.exe
where the fix is. Is there something we can do about this? Without modifying perl.exe
in this minor way on windows, we can't solve the problem.
I'm trying to install PAR::Packer on an ActivePerl 5.16.3 x86 on a RHEL 6.10 x64.
It fails to install. Here is the command prompt
[/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.
Here is the content of /root/.cpanm/work/1606926712.5624/build.log
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.
I also have an older Perl version installed, but not in PATH.
[/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
Any idea how to get this to install on the ActivePerl version?
I had no problem installing cpanm there.
Thank you.
I am trying to use pp to create an executable of an application that needs Mojo on Windows 10, but the exe fails with the following error:
Unable to open html entities file (C:\Users\de\AppData\Local\Temp\par-6663\cache-9973dd41d00e8bee27c9630746780ae38da71709\inc\lib\Mojo\resources\html_entities.txt): No such file or directory at C:\Users\de\AppData\Local\Temp\par-6663\cache-9973dd41d00e8bee27c9630746780ae38da71709\inc\lib/Mojo/Base.pm line 14.
The following command does not help:
-a "C:\Strawberry\perl\vendor\lib\Mojo\resources;Mojo/resources"
If I open the package once the software has run once, there is no folder "resources" in Mojo
(cross-posted in https://www.perlmonks.org/?node_id=11133963)
When I use command:
pp -f Crypto -F Crypto -M Filter::Crypto::Decrypt -o test test1.pl
The resulting package could run in this Linux no problem. But get error when I run it on another Linux system.
Is the resulting package portable for all Linux?
For parallel build modules must be installed into blib/ before make recurse into "myldr/".
Make process myldr directory via 'subdirs ::' double-colons rule, according to
http://web.mit.edu/gnu/doc/html/make_toc.html#SEC40 these rules are processed individually and
in order they appear in the Makefile.
MY::postamble() function that was added into Makefile.PL by the the commit d4c4619 insert addition
'subdirs :: ' rule at the end of Makefile, and general 'subdirs ::' rule could be processed before it
at some parallels levels of make.
MY::depend() function should be used instead of MY::postamble() to place custom
'subdirs :: pm_to_blib' rule before automatic one.
We recently rebuilt our Perl-5.32.1 for rs6000_71 (AIX) using an updated compiler there. PAR::Packer built/installed by this bin/perl creates executables that are not executable, instead reporting
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.
We've dumped the header, it looks pretty damaged. We've compared the headers of this output with earlier ones that run correctly and there are a few offsets in the header that are a bit off, and one that is way off (looks like a high-bit got set).
Our hypothesis is that the new compiler creates a binary with a slightly different object properties that PAR::Packer mis-identifies.
We can share with you these headers, binary diffs, and other information, but what we really want is help in locating where in the PAR::Packer code the header of the output is calculated - then we could localize the issue better to figure this out. We imagine that rs6000_71 is a platform few have handy to track this down with; we have one handy and might figure this out with some help.
Thank you.
attached "Hello, World" example that replicates this problem on rs6000_71
pp_rs6000_test.tgz
It is a common trick to use a module also as a script by checking caller()
to be false in scalar context. Such a script when packaged with PAR will behave as a module because caller()
will return PAR
, which is different from running the script without packaging. A workaround is to test caller()
to be empty or PAR
, but this requires modification of the original script. A method used in Call::From
could be used to fake the script as being run in top level (so that caller()
returns an empty string).
I'm sure this is impossible but it would be awesome if the compiled product could have a code signature added.
I am still testing PAR::Packer
to generate an exe from the Perl script in issue #21:
#! /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;
}
This time I am using perl
version 5.30.0 on Ubuntu 20.04. I run:
$ 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.
If I now transfer the p2.exe
to a docker container running Ubuntu 16.04 and perl
version 5.22.1 and execute it:
$ ./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)
So this did not work. Seems like pp_autolink
detected libcrypto.so.1.1
but is this the same as libcrypt.so
(note the missing o
) from the error message? For the other error from libm.so.6
, does it mean that --link /lib/x86_64-linux-gnu/libm.so.6
somehow did not work properly? Or that it should also link with libc.so
? Any ideas?
command:
pp -o test -A addlist.txt test1.pl
content in addlist.txt:
lib_3.pm
lib
there are lib_1.pm and lib_2.pm under folder lib test1.pl call functions defined in lib_1.pm and lib_2.pm and lib_3.pm
after I run the command above, I get error:
for packingin/pp: cannot find file or directory lib_3.pm
for packingin/pp: cannot find file or directory lib
Although I get the error, the output file from pp can print correct output. Who can tell me why?
Hi. Consider this script:
#! /usr/bin/env perl
use strict;
use warnings;
use Mojo::Util;
print "Test Mojo\n";
if I pack this script with:
$ pp -x -c test.pl
and then run the generated executable (Ubuntu 21.04, perl version 5.32.0):
$ ./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.
See this question on stackoverflow.com for more information.
The problem seems to be that the file Mojo/resources/html_entities.txt
was not included in the archive. Is this a bug, or is it expected behavior?
how to compile executable file runing in centos6(glibc2.12) and centos7(glibc2.17)
Hello,
I am trying to upgrade my ParPacker on a windows server but when i run cpanm
I get the following:
If I look at the log, it seems like the build process can't find the source files, which is strange since other packages are installing without an issue.
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
This doesn't seem like the other issues people have run into with tests failing so I am running out of ideas and am hoping that someone else has sorted this out.
perl 5.32 removed utf8_heavy.pl
in this commit which breaks pp -u. I added a testcase for the -u switch in a pull request #26. I don't know how to fix this. It seems to me, that -u could be made a no-op for new perls :
➜ 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)
Migrated from rt.cpan.org#132802 (status was 'new')
Requestors:
From [email protected] on 2020-06-10 20:18:23
:
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
Hello, I dunno if this is an inconsitency or a minor bug, but recently I noticed with some surprise, that on my strawberry a packed small program globbed * received as argument: if we read the source in the right manner this should not happen.
while in plain perl
perl -we "print join qq(\n), @ARGV" *
just * is printed
the packed version expands the glob:
pp -e "print join qq(\n), @ARGV" -o printargv.exe
Calling printargv.exe *
all plain files and dirs in current dire are returned (no dot files in the list..)
And calling printargv.exe *.pl
all .pl file in current directory are returned.
I've asked at perlmonks: see this thread for many other details about my version of perl.
thanks for looking
Hello
I'm using the command
pp -f Crypto -M Filter::Crypto::Decrypt -o script.pl mojo.pl
Plugin "HeaderCondition" missing, maybe you need to install it?
BEGIN failed--compilation aborted at script/script.pl line 6.
Hello
I'm using the command
#!/usr/bin/perl
use Mojolicious::Lite -signatures;
use Mojolicious::Static;
use POSIX qw(strftime);
use HTML::Entities;
use DBI;
use JSON;
get '/' => 'index';
app->mode('production');
app->secrets(['U0dWaFpHVnlRMjl1WkdsMGFXOXVmZHJ0dDU0NnlqNzY1eXRqeXR5dHNkZmRmZHM']);
app->start;
DATA
@@ index.html.ep
<title>Test</title> Test....t/20-pp.t ................ skipped: 'perl' not found
Unrelated to the real bug in t/85-crt-glob.t
, but I'm curious: can you check what the value
of $Config{startperl}
of your perl is and why main->can_run($Config{startperl})
(in t/20-ppt
) fails?
Migrated from rt.cpan.org#133999 (status was 'open')
Requestors:
From [email protected] on 2021-01-06 14:13:16
:
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]
From [email protected] on 2021-01-06 22:25:55
:
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
I have a linux binary (compiled with simply "pp -x -o file_out.bin file_in.pl") that runs every 5 minutes.
On systems running GLIBC2.17, I have no issues. However, since I need to support some older RHEL6 boxes, I have to compile this perl script on a box with GLIBC2.12. The built file will run for a few days, or a day, then corrupt itself, changing it's size from about 7MB down to 2.9MB. I can't find a reason for this, and don't know why the file would ever try to update itself on execution. I'm wondering if anyone else has run into anything like this. I've been using pp for years, and never seen this.
I am trying to create an .exe
from the following Perl script:
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;
}
On Windows 10, with Strawberry Perl, perl version 5.30.1, running pp
from command prompt:
pp -o p4.exe -x p.pl
produces an executable p4.exe
that runs fine on the current machine and produces output ok
. When I upload the p4.exe
to another windows 10 machine that does not have perl
installed and run it I get output:
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.
If I run pp
with verbose option, I can see that it packages LWP::Protocol::https
:
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
Any ideas what is going on?
See also this issue on stackoverflow.com
Migrated from rt.cpan.org#132811 (status was 'open')
Requestors:
From [email protected] on 2020-06-12 13:37:57
:
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
From [email protected] on 2020-06-12 23:44:29
:
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
From [email protected] on 2020-06-13 01:35:12
:
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
From [email protected] on 2020-06-13 02:04:55
:
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.
From [email protected] on 2020-06-13 06:59:53
:
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.
From [email protected] on 2020-06-13 10:44:03
:
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
From [email protected] on 2020-06-13 22:45:02
:
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.
From [email protected] on 2020-06-14 03:32:46
:
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.
From [email protected] on 2020-06-14 15:24:18
:
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
From [email protected] on 2020-06-14 15:49:03
:
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
From [email protected] on 2020-06-14 20:21:45
:
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
Migrated from rt.cpan.org#69848 (status was 'open')
Requestors:
From [email protected] on 2011-07-27 21:41:15
:
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
______________________________________________________________________
From [email protected] on 2011-07-27 22:03:35
:
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
From [email protected] on 2011-07-28 13:43:16
:
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
______________________________________________________________________
From [email protected] on 2011-08-01 14:26:13
:
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
> ______________________________________________________________________
From [email protected] on 2011-08-02 09:26:22
:
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
From [email protected] on 2011-08-02 21:55:58
:
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
______________________________________________________________________
From [email protected] on 2011-08-03 06:38:43
:
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
From [email protected] on 2011-08-09 10:52:49
:
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";
}
From [email protected] on 2020-04-22 13:14:05
:
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
From [email protected] on 2020-04-22 15:22:03
:
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
From [email protected] on 2020-04-22 15:49:39
:
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
From [email protected] on 2020-04-22 16:04:49
:
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
From [email protected] on 2020-04-23 16:09:26
:
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.
From [email protected] on 2020-04-25 11:00:18
:
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
There is a text file named 11.txt has content:
1234567
under folder: ./data
I use command:
pp -o test -a ./data test1.pl
to pack folder data into result package test.
In test1.pl I write code:
exec “gedit ./data/11.txt”
When I run result package, an empty file named 11.txt is opened. How to access file I packed?
I cannot find a strawberry perl version that works. Last version I had working was Perl 5.8.9.4 with PP 1.010.
I am lost, please help.
t/20-pp.t (Wstat: 512 Tests: 34 Failed: 2)
Failed tests: 33-34
Non-zero exit status: 2
Files=17, Tests=243, 2684 wallclock secs ( 0.39 usr + 0.23 sys = 0.62 CPU)
Result: FAIL
Failed 1/17 test programs. 2/243 subtests failed.
gmake: *** [Makefile:1033: test_dynamic] Error 255
RSCHUPP/PAR-Packer-1.050.tar.gz
C:\Users\l0106086\Documents\strawberry-perl-5.32.0.1-64bit-portable\c\bin\gmake.exe test -- NOT OK
//hint// to see the cpan-testers results for installing this module, try:
reports RSCHUPP/PAR-Packer-1.050.tar.gz
Stopping: 'install' failed for 'R/RS/RSCHUPP/PAR-Packer-1.050.tar.gz'.
I've got a perl
(5.32.1) built using MSVC (Visual Studio 2019). I'm now
attempting to leverage that perl build and 'PAR::Packer'. Once I install all the
required modules and pack a script, it runs fine on the build host. As soon as I
take it to a host which no longer has the required runtime, I get a pop-up
titled “hello.exe – System Error” with the message “The code execution cannot
proceed because VCRUNTIME140.dll was not found. Reinstalling the program may fix
this problem.”.
I've tried to use the -l
option to explicitly include the shared libs (DLLs), but
that has not helped.
I've also tried applying the patch below, but that has not helped either.
I'm looking for assistance in how to proceed to make sure PAR::Packer will
allow me to create a portable exe.
Patch:
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 };
}
Simple hello.pl
script:
#!/usr/bin/env perl
use strict;
use warnings;
print "Hello, World!\n";
I've installed my modules in a local lib, so my pp
command is run as follows:
perl -Iextlib-MSWin32-x64-multi-thread\lib\perl5 extlib-MSWin32-x64-multi-thread\bin\pp -o hello.exe hello.pl
Here are the dependencies according to dumpbin
:
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
By comparison, a similarly built hello-sp.exe
using Strawberry Perl (happened
to have 5.32.0.1 on this system), I see the following dependencies listed below
and that file executes not only on the "build" host, but also another where SP
is NOT installed.
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
If you write a batch file to use pp to compile, doesn't exit in a way that allows the batch file to continue.
@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
In this example, after pp is executed there will be no further text (no "Success" or "Failed" message).
If you try to fork it doesn't exit that either:
@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
This will start a new Window for the compiler, after it's done it will just stay at a command prompt, not exiting like it should. (If you type exit in the popup prompt, the batch file will resume in this case but it pretty much is useless for automation.) Oddly adding && exit
to the command doesn't help at all.
Strawberry Perl (x64) v5.30.2
PAR::Packer 1.052
Windows 10.0.19041.985
UPDATE:
Poked around and noticed pp is a batch file so I changed the code to:
call pp -o compiled.exe source.pl
and now it works properly.
Should probably be documented if nothing else.
"/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.
Seems, that it removes perl locations from @inc.
Hello,
I'm not able to use symbolic link(s) to call the packed script(s), on Windows 10 and Server 2016.
Please see this link for example code and details : https://perlmonks.org/?node_id=11134716
If it's not supported, I'd suggest to document it (maybe also the fact that macOS aliases and Windows shortcuts won't work, it's not necessarily obvious for everyone).
Thanks
pp --link=/usr/lib64/libc-2.17.so -o test test.pl
I make in centos7 and execute in centos6.....how to compile the glibc into the executable file?
./test: /lib64/libc.so.6: version `GLIBC_2.14' not found (required by ./test)
How to resolve this error?
root@athusbsd:/usr/local/www/apache24/data # uname -a
FreeBSD bsd.local 13.0-RELEASE-p3 FreeBSD 13.0-RELEASE-p3 #0: Tue Jun 29 19:46:20 UTC 2021 [email protected]:/usr/obj/usr/src/amd64.amd64/sys/GENERIC amd64
when i run
root@athusbsd:/usr/local/www/apache24/data # pp -x -c -o a.bin tt.pl
/tmp/GEekK1zmPl syntax OK
root@athusbsd:/usr/local/www/apache24/data # cat a.bin
^@par-^@%s%stemp-%u%s^@.^@perlio^@PAR_CLEAN=^@tmp^@%s%stemp-%u-%u%s^@/^@PERL5LIB^@ USERNAME^@PAR_GLOBAL_DEBUG^@/tmp/^@parl^@PAR_DEBUG^@PAR_CACHE^@PAR_GLOBAL_TMPDIR^@%02x^@%s%s%s%s^@%s: extraction of %s (custom Perl interpreter) failed (er
rno=%i)
^@Par^@LD_LIBRARY_PATH^@temp^@tmpdir^@.par^@PAR_TEMP^@System^@/proc/%i/%s^@PAR_CLEAN^@PAR_SPAWNED^@%s: private subdirectory %s is unsafe ( please remove it and retry your operation)
^@PAR_PROGNAME^@PAR_INITIALIZED^@%s%scache-%s%s^@%s: extraction of %s failed (errno=%i)
^@PAR_GLOBAL_TEMP^@%s/%s^@1^@PAR_GLOBAL_CLEAN^@user^@path^@%s: creation of private cache subdirectory %s failed (errno= %i)
Script does not run in apache
Internal Server Error
[Mon Aug 16 10:18:56.832747 2021] [cgi:error] [pid 8594] [client 192.168.1.103:6969] End of script output before headers: xx.pl
Migrated from rt.cpan.org#127538 (status was 'open')
Requestors:
From [email protected] on 2018-10-31 16:51:13
:
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
From [email protected] on 2018-11-03 14:57:59
:
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
I get the error in the subject when there is a second perl in the path which has a different version. There is no error when there is only one perl in the path.
Tested on Windows using PAR::Packer 1.047 and PAR 1.015 (latest).
Steps to reproduce are below. These use portable Strawberry perls managed via berrybrew, but it also occurs when the second perl is a standard installation. The same happens with the order of perls reversed.
I have not been able to track down where it is coming from.
set PATH=C:\berrybrew\5.26.2_64_PDL\perl\site\bin;C:\berrybrew\5.26.2_64_PDL\perl\bin;C:\berrybrew\5.26.2_64_PDL\c\bin;C:\berrybrew\5.28.0_64_PDL\perl\site\bin;C:\berrybrew\5.28.0_64_PDL\perl\bin;C:\berrybrew\5.28.0_64_PDL\c\bin;%PATH%
pp -e "1"
An example result is:
SHA.c: loadable library and perl binaries are mismatched (got handshake key 0000000000028fa8, needed 0000000000000000)
If I run it multiple times then I get different handshake values, presumably due to different libraries being loaded.
Thanks,
Shawn.
I have a script.pl that runs fine and finishes quickly. If I turn it into a Windows 10 executable script.exe using pp and then run script.exe then it seems to hang. I would like to be able to have pp produce an executable that runs the perl script in the perl debugger, so I can figure out conveniently where the difference comes from. I.e., I would like to be able to make the pp-ed executable act like perl -d script.pl
instead of perl script.pl
.
I've tried adding BEGIN { require 'perl5db.pl' }
at the start of script.pl (inspiration taken from perldebguts) but that didn't have the desired effect.
I've tried beginning my script with #!/bin/perl -d
but then script.exe fails with a "mkdir" error about an "Invalid argument" involving AppData\Local\par-HASH\cache-HASH.
I've tried hacking the PAR/pp source code by looking for the places where I think perl.exe gets started and then injecting "-d", but to no avail.
Migrated from rt.cpan.org#132055 (status was 'open')
Requestors:
Attachments:
From [email protected] on 2020-03-04 23:57:24
:
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.
From [email protected] on 2020-03-05 08:31:08
:
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
From [email protected] on 2020-03-05 16:22:46
:
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
From [email protected] on 2020-03-05 16:23:59
:
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
From [email protected] on 2020-03-06 05:07:28
:
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?
From [email protected] on 2020-03-06 11:27:12
:
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
From [email protected] on 2020-03-06 11:33:30
:
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
When building PAR with strawberryperl portable, parldyn (par.exe -B -Oparldyn.exe
packs both lib/Config.pm and vendor/lib/Portable/Config.pm. par.exe -b -Oparltiny.exe
packs only vendor/lib/Portable/Config.pm. This is the desired behavior. However, when launching, things go wrong in parltiny:
Global symbol "%Config" requires explicit package name (did you forget to declare "my %Config"?) at C:/.../perl/lib/Errno.pm line 12.
Global symbol "%Config" requires explicit package name (did you forget to declare "my %Config"?) at C:/.../perl/lib/Errno.pm line 12.
Execution of C:/.conan/a84e8d/1/perl/lib/Errno.pm aborted due to compilation errors.
Compilation failed in require at C:/.../perl/lib/File/Temp.pm line 152.
BEGIN failed--compilation aborted at C:/.../perl/lib/File/Temp.pm line 152.
Compilation failed in require at C:/.../perl/vendor/lib/Archive/Zip.pm line 11.
BEGIN failed--compilation aborted at C:/.../perl/vendor/lib/Archive/Zip.pm line 11.
Compilation failed in require at -e line 141.
This seems to behappening because the function added to @inc is only checking a suffix match on the path:
Lines 304 to 307 in 5a98e29
So when use Config;
gets resolved to a call looking with $module
equal to 'Config.pm', it thinks 'Portable/Config.pm' is a match, and returns the wrong file's body. So the wrong thing gets loaded, and %Config
isn't defined (and then things go downhill from there, of course, given how central Config.pm is).
As far as I can tell, there was at least a risk of this happening in the parldyn case too, since the order of keys in foreach (keys %require_list)
is not specified. If it had happened to check Portable/Config.pm
before Config.pm
, it could have picked the wrong thing for parldyn (where both were in %require_list
) too.
There doesn't seem to be any prefix on the files here, so I'm not sure why this is a regex suffix match instead of just equality:
@@ -304,4 +304,4 @@
foreach (keys %require_list) {
- next unless /\Q$module\E$/;
+ next unless $_ eq $module;
$key = $_; last;
}
Is there a way to suppress these types of messages?
Subroutine DESTROY redefined at /usr/local/share/perl5/site_perl/Mojo/IOLoop/Client.pm line 25
These are polluting the output of pp
Steps to reproduce are below.
I hit this problem when packing a file that depended on FFI::Platypus, which loads its config.pl file using the do file
syntax, with an absolute path for the filename. As documented, the file path is added to %INC as both key and value. https://perldoc.perl.org/functions/do.html
When PAR tries to unpack it, Archive::Zip::Archive throws an error due to the colon in the file name.
I am not sure of the best approach to handle it. If the file is in a perl directory structure then the path could be left-truncated so it is packed and unpacked along with the other files under inc/lib. If it is elsewhere on the system, though, then that won't work so well.
As a data point, 7-zip converts the colon to an underscore when extracting, but does not allow the folder to be renamed inside the archive.
(Tested with PAR::Packer 1.045, Strawberry perl 5.26.1 via berrybrew).
Generate a file called file_to_do.pl. The contents don't matter greatly:
sub nonesuch {
return 1;
}
Then pack it using do file
with the absolute path name:
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}"
which results in:
C:/Users/user/file_to_do.pl listed at C:/Users/user/file_to_do.pl
then call the newly created exe file:
a.exe
which results in:
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.
Running macOS 10.14.6. I feel like I've compiled this previously, but upgrading to the newest PAR failed. Sharing some other debugging messages.
I think these articles may be related to the problem?
I see plenty of files here, like this one:
/usr/local/lib/gcc/9/libgcc_ext.10.4.dylib
Some other output, which may be useful:
$ which ld
/usr/bin/ld
$ ld -v dummy
@(#)PROGRAM:ld PROJECT:ld64-450.3
BUILD 18:16:53 Apr 5 2019
configured to support archs: armv6 armv7 armv7s arm64 arm64e arm64_32 i386 x86_64 x86_64h armv6m armv7k armv7m armv7em
Library search paths:
/usr/lib
/usr/local/lib
Framework search paths:
/Library/Frameworks/
/System/Library/Frameworks/
(installed with -f)
$ 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
The logic in
Lines 33 to 36 in 5a98e29
If perl.h has not been included, this defaults to BYTEORDER 0x12345678, which implies a 64-bit swap operation down at
Lines 154 to 166 in 5a98e29
However, since it does not define U64TYPE or USE_64_BIT_INT, PAR_ULONG is only a 32-bit type:
Line 51 in 5a98e29
When building on windows-x86 using strawberryperl 5.28.1, this shows up a warning from gcc
sha1.c:153:4: warning: right shift count >= width of type [-Wshift-count-overflow]
T >>= 32;
But it seems like the real issue isn't really on that line, but up here where BYTEORDER and PAR_ULONG got out of sync. There's a lot of ways this could get fixed, but it seems like the simplest and probably best would be to just #include "config.h"
in boot.c before it brings in mktemp.c, so this and main.c would be consistent about which types are used.
Hello i'm running the command
pp -f Crypto -M Filter::Crypto::Decrypt -o hello hellp.pl
And I get the following message. I couldn't resolve it.
/usr/bin/perl: symbol lookup error: /usr/lib/perl5/site_perl/5.34.0/x86_64-linux/auto/Filter/Crypto/CryptFile/CryptFile.so: undefined symbol: OPENSSL_init_crypto
[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
Script runs normally on http://localhost/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]#
When I run the script via browser http://localhost/xx.pl
Internal Server Error
The server encountered an internal error or misconfiguration and was unable to complete your request.
[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>
Migrated from rt.cpan.org#133081 (status was 'new')
Requestors:
From [email protected] on 2020-07-30 12:35:46
:
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.
I created a Tk GUI app using AS Perl v5.20.2 with pp.pm v 0.992 on Windows 10 .
The GUI does a Win32::Process::Create to basically fork off a task to do URL fetches asynchronously (so as not to lock up the GUI part).
After building with pp, everything runs ok (w or w/o --gui switch), but I get 2 copies of the GUI and 2 copies of the forked off async app showing up in Task Manager.
When I kill the forked off async task from the GUI task and exit the GUI task, both of the GUI processes exit OK, but only one of the async processes gets killed. This leaves me with multiple async tasks floating around - one per run.
I generated an executable on fedora:
Fedora release 35 (Thirty Five)
NAME = "Fedora Linux"
VERSION = "35 (Workstation Edition)"
I ran the executable on Debian 11 and the result is:
./EPVzParserAgentsHandler: /lib/x86_64-linux-gnu/libc.so.6: version GLIBC_2.33 'not found (required by ./EPVzParserAgentsHandler) ./EPVzParserAgentsHandler: /lib/x86_64-linux-gnu/libc.so.6: version
GLIBC_2.34 'not found (required by ./EPVzParserAgentsHandler)
while everything is running fine on Fedora, how can this problem be avoided?
I have built a website on nginx and ran a execute the binary file made by par::packer (perl script). However, it didn't work.
The binary file can work as well on terminal but not web service.
No a log file generated make me hard to solve the problem.
Any suggestion is appreciated
Thanks!
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.