Skip Menu |

This queue is for tickets about the PAR-Packer CPAN distribution.

Report information
The Basics
Id: 57948
Status: resolved
Priority: 0/
Queue: PAR-Packer

People
Owner: RSCHUPP [...] cpan.org
Requestors: mjk [...] iki.fi
Cc:
AdminCc:

Bug Information
Severity: (no value)
Broken in: (no value)
Fixed in: (no value)



Subject: Bug report: pp-generated executable and a missing dependency libgcc_s_sjlj-1.dll
Date: Fri, 28 May 2010 14:20:43 +0300
To: bug-PAR-Packer [...] rt.cpan.org
From: mjk [...] iki.fi
Platform: Windows XP SP3 32-bit, Windows Vista SP2 32-bit Perl version: Strawberry Perl 5.12.0.1 PAR::Packer version: 1.004 Module installed via CPAN client PAR::Packer pp command generates executable files under Windows environment that depend on shared library called "libgcc_s_sjlj-1.dll". It seems that parl.exe depends on this library. If the target platform does not have this shared library somewhere in the path, the following error message will be displayed: --------------------------- pingtest.exe - Unable To Locate Component --------------------------- This application has failed to start because libgcc_s_sjlj-1.dll was not found. Re-installing the application may fix this problem. --------------------------- OK --------------------------- The project was compiled with the command-line: pp -o pingtest.exe pingtest.pl If the libgcc_s_sjlj-1.dll is copied from the Strawberry Perl system (C:\Strawberry\perl\bin\libgcc_s_sjlj-1.dll) to the same directory with the pp-generated executable, the executable will work correctly. Trying to include the DLL into the packed executable with an -a option does not solve the problem. Side-note: for some reason a dependency checker (for example cygcheck) does not see that the generated executable depends on the libgcc_s_sjlj-1.dll. Best regards, Matti Kärki
On Fri May 28 07:21:05 2010, mjk@iki.fi wrote: Show quoted text
> PAR::Packer pp command generates executable files under Windows > environment that depend on shared library called > "libgcc_s_sjlj-1.dll". It seems that parl.exe depends on this library.
Known problem, buried deep in #57272. Can you please try the patch attached to https://rt.cpan.org/Ticket/Display.html?id=57272#txn-776549 Note that you must rebuild PAR::Packer with this patch, install it and then repack your script to test the fix. Cheers, Roderich
Subject: Re: [rt.cpan.org #57948] Bug report: pp-generated executable and a missing dependency libgcc_s_sjlj-1.dll
Date: Fri, 28 May 2010 22:49:39 +0300
To: bug-PAR-Packer [...] rt.cpan.org
From: mjk [...] iki.fi
Show quoted text
> > Known problem, buried deep in #57272. > > Can you please try the patch attached to > https://rt.cpan.org/Ticket/Display.html?id=57272#txn-776549 > > Note that you must rebuild PAR::Packer with this patch, install it > and then repack your script to test the fix. >
I tried the patch mentioned above. The problem still exists. The end result of the pp still depends on the libgcc_s_sjlj-1.dll. My guess is that including this library inside the packed script does not help because the executable for some reason requires the DLL at pretty early stage of the execution. So, the DLL inside the packed script has no effect in this case. If I have time, I have to investigate, what the PAR::Packer is doing while compiling the stub. I imagine that it should be possible to compile the stub in such way that this DLL is not needed when the stub part of the package is executing. -Matti
CC: par [...] perl.org
Subject: Re: [rt.cpan.org #57948] Bug report: pp-generated executable and a missing dependency libgcc_s_sjlj-1.dll
Date: Sat, 29 May 2010 14:03:05 +0100
To: bug-PAR-Packer [...] rt.cpan.org
From: Mark Dootson <mark.dootson [...] znix.com>
Hi, perl5xx.dll depends on libgcc_s_sjlj-1.dll, so libgcc_s_sjlj-1.dll needs to be packed with, and extracted with perl5xx.dll before any Perl code is run at all. Cheers Mark On 28/05/2010 20:49, mjk via RT wrote: Show quoted text
> Fri May 28 15:49:57 2010: Request 57948 was acted upon. > Transaction: Correspondence added by mjk@iki.fi > Queue: PAR-Packer > Subject: Re: [rt.cpan.org #57948] Bug report: pp-generated executable and a missing dependency libgcc_s_sjlj-1.dll > Broken in: (no value) > Severity: (no value) > Owner: RSCHUPP > Requestors: mjk@iki.fi > Status: open > Ticket<URL: http://rt.cpan.org/Ticket/Display.html?id=57948> > >
>> >> Known problem, buried deep in #57272. >> >> Can you please try the patch attached to >> https://rt.cpan.org/Ticket/Display.html?id=57272#txn-776549 >> >> Note that you must rebuild PAR::Packer with this patch, install it >> and then repack your script to test the fix. >>
> > I tried the patch mentioned above. The problem still exists. The end > result of the pp still depends on the libgcc_s_sjlj-1.dll. My guess is > that including this library inside the packed script does not help > because the executable for some reason requires the DLL at pretty > early stage of the execution. So, the DLL inside the packed script has > no effect in this case. > > If I have time, I have to investigate, what the PAR::Packer is doing > while compiling the stub. I imagine that it should be possible to > compile the stub in such way that this DLL is not needed when the stub > part of the package is executing. > > > -Matti > > >
On Sat May 29 09:03:30 2010, mark.dootson@znix.com wrote: Show quoted text
> perl5xx.dll depends on libgcc_s_sjlj-1.dll, so libgcc_s_sjlj-1.dll > needs > to be packed with, and extracted with perl5xx.dll before any Perl code > is run at all.
Indeed, the problem is that the custom Perl interpreter "included" in every packed executable is linked dynamically against perl5xx.dll. If you do pp -o foo.exe .... and run foo.exe at least once you'll find the corresponding cache area TMP\par-USER\cache-SHA1CHECKSUM contains a file called foo.exe, too. That's the custom Perl interpreter (it's always the same file). Now, if we linked this executable dynamically, you'll also find a copy of perl5xx.dll in this directory. But for Strawberry that's not enough, it needs libgcc_s*.dll there, too. So I see two possible options: - stick with a dynamically linked custom Perl and modify (conditionally for Strawberry only) the whole load_me_* shebang in myldr and add a load_me_3 file that would contain libgcc_s_*.dll (which would get extracted alongside par.exe and perl512.dll) - link the custom Perl statically, then the whole second bootstrap phase is omitted and the problem goes away I definitely don't want to touch the load_me stuff with a ten-foot pole, so I experimented with the latter option. However, even after tweaking myldr/Makefile by hand I couldn't produce a par.exe there that was NOT dynamically linked against perl512.dll. @Mark: Do you know why even g++ main.o my_par_pl.o -Wl,-Bstatic -Lc:\strawberry\perl\lib\CORE -lperl512 -o par.exe generates par.exe with a reference to perl512.dll? Cheers, Roderich
Subject: Re: [rt.cpan.org #57948] Bug report: pp-generated executable and a missing dependency libgcc_s_sjlj-1.dll
Date: Sat, 29 May 2010 22:15:13 +0300
To: bug-PAR-Packer [...] rt.cpan.org
From: mjk [...] iki.fi
Show quoted text
> > Known problem, buried deep in #57272. > > Can you please try the patch attached to > https://rt.cpan.org/Ticket/Display.html?id=57272#txn-776549 > > Note that you must rebuild PAR::Packer with this patch, install it > and then repack your script to test the fix. >
OK, now that I know what to look for and I think I have a little bit better understanding of the anatomy of the pp-generated executables, I re-checked the patch (bug #57272). It does include the DLL in the PAR package, but when I execute the executable, the temporary directory only has the following files: - perl512.dll - pingtest.exe In other words, the DLL is not extracted from the package. Bad news is that according to the cygcheck, both of these files depend on the libgcc_s_sjlj-1.dll. So, if I have understood previous messages correctly, it seems that all fingers are actually pointing to the MinGW. -Matti
CC: par [...] perl.org
Subject: Re: [rt.cpan.org #57948] Bug report: pp-generated executable and a missing dependency libgcc_s_sjlj-1.dll
Date: Sun, 30 May 2010 13:20:04 +0100
To: bug-PAR-Packer [...] rt.cpan.org
From: Mark Dootson <mark.dootson [...] znix.com>
Hi, On 29/05/2010 17:55, RSCHUPP via RT wrote: Show quoted text
> > So I see two possible options: > - stick with a dynamically linked custom Perl and > modify (conditionally for Strawberry only) the whole > load_me_* shebang in myldr and add a load_me_3 file that > would contain libgcc_s_*.dll (which would get extracted > alongside par.exe and perl512.dll) > - link the custom Perl statically, then the whole second > bootstrap phase is omitted and the problem goes away > > I definitely don't want to touch the load_me stuff with a > ten-foot pole, so I experimented with the latter option. > However, even after tweaking myldr/Makefile by hand I > couldn't produce a par.exe there that was NOT dynamically > linked against perl512.dll. > > @Mark: Do you know why even > > g++ main.o my_par_pl.o -Wl,-Bstatic -Lc:\strawberry\perl\lib\CORE > -lperl512 -o par.exe > > generates par.exe with a reference to perl512.dll? > > Cheers, Roderich >
I'm not absolutely certain of the total effect of passing -static to ld on windows. For '-lperl512' what matters is what is contained in perl512.lib or libperl512.a. I don't think you can mix and match your linking model on Windows. So if you had a static perl.exe (or par.exe) you could not then load separate xs code dynamically - you would have to compile in all the xs modules you require. That's why, by default, you don't get a static perl built on MSWin. It is not generally useful. In a dynamic perl, all the xs dll's are dynamically linked to perl512.dll. You can't mix and match static / dynamic linking. You have to add a load_me_3 file or some windows specific function that does the same thing, I'm afraid. Regards Mark
On Sun May 30 08:20:47 2010, mark.dootson@znix.com wrote: Show quoted text
> I don't think you can mix and match your linking model on Windows. So if > you had a static perl.exe (or par.exe) you could not then load separate > xs code dynamically - you would have to compile in all the xs modules > you require. That's why, by default, you don't get a static perl built > on MSWin. It is not generally useful.
Thanks for the explanation, Mark. I'll hold my nose and try the "load_me_3" approach then, stay tuned. Cheers, Roderich
Subject: Re: [rt.cpan.org #57948] Bug report: pp-generated executable and a missing dependency libgcc_s_sjlj-1.dll
Date: Tue, 01 Jun 2010 11:01:05 +0200
To: bug-PAR-Packer [...] rt.cpan.org
From: Steffen Mueller <smueller [...] cpan.org>
RSCHUPP via RT wrote: Show quoted text
> Queue: PAR-Packer > Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=57948 > > > On Sun May 30 08:20:47 2010, mark.dootson@znix.com wrote:
>> I don't think you can mix and match your linking model on Windows. So if >> you had a static perl.exe (or par.exe) you could not then load separate >> xs code dynamically - you would have to compile in all the xs modules >> you require. That's why, by default, you don't get a static perl built >> on MSWin. It is not generally useful.
> > Thanks for the explanation, Mark. > I'll hold my nose and try the "load_me_3" approach then, stay tuned.
Hey, I survived modifying the load_me stuff, too! But I probably have lower standards :) More seriously, I'm pretty sure you already know how it works, but it's just a vehicle of embedding an arbitrary file as a variable in C code & extracting it when run. I believe I refactored some of it to be slightly less insane a few years back. It's still totally a kludge, but alas, I don't have a good idea of how we could work around it. Except that statically linking a libz for some minor compression and reduction of the executable file size would be really cool. Not saying *you* should do that, mind you. Cheers, Steffen
RT-Send-CC: mark.dootson [...] znix.com, par [...] perl.org, smueller [...] cpan.org
I just released PAR::Packer 1.005 that should fix the issue with libgcc*.dll on Strawberry Perl 5.12. Cheers, Roderich
Subject: Re: [rt.cpan.org #57948] Resolved: Bug report: pp-generated executable and a missing dependency libgcc_s_sjlj-1.dll
Date: Sun, 06 Jun 2010 19:17:14 +0300
To: bug-PAR-Packer [...] rt.cpan.org
From: mjk [...] iki.fi
First of all, thank you very much for reacting so quickly to my bug report. But something is not right with the 1.005. I tried to upgrade the package and the build process stops because of the parldyn.exe. I tried this also with the clean Strawberry system and it still fails. However, the parldyn.exe is in the script directory under the C:\strawberry\cpan\build\PAR-Packer-1.005-fFWniH directory structure. Here is the log: Running make for R/RS/RSCHUPP/PAR-Packer-1.005.tar.gz Has already been unwrapped into directory C:\strawberry\cpan\build\PAR-Packer- 1.005-fFWniH CPAN.pm: Going to build R/RS/RSCHUPP/PAR-Packer-1.005.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/Obfuscate.pm blib\lib\PAR\Filter\Obfuscate.pm cp lib/PAR/Filter/PodStrip.pm blib\lib\PAR\Filter\PodStrip.pm cp lib/PAR/StrippedPARL/Base.pm blib\lib\PAR\StrippedPARL\Base.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/StrippedPARL/Dynamic.pm blib\lib\PAR\StrippedPARL\Dynamic.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 cp lib/PAR/StrippedPARL/Static.pm blib\lib\PAR\StrippedPARL\Static.pm C:\strawberry\perl\bin\perl.exe sha1.c.PL sha1.c gcc -c -s -O2 -DWIN32 -DHAVE_DES_FCRYPT -DUSE_SITECUSTOMIZE -DPERL_IMPLICIT_CON TEXT -DPERL_IMPLICIT_SYS -fno-strict-aliasing -mms-bitfields -DPERL_MSVCRT_READF IX -I"C:\strawberry\perl\lib\CORE" -DLOAD_MY_LIBGCC -DPARL_EXE=\"parl.exe\" -s -O2 sha1.c dmake: Warning: -- Found file corresponding to virtual target [mktmpdir.h]. dmake: Warning: -- Found file corresponding to virtual target [mktmpdir.c]. dmake: Warning: -- Found file corresponding to virtual target [main.c]. gcc -c -s -O2 -DWIN32 -DHAVE_DES_FCRYPT -DUSE_SITECUSTOMIZE -DPERL_IMPLICIT_CON TEXT -DPERL_IMPLICIT_SYS -fno-strict-aliasing -mms-bitfields -DPERL_MSVCRT_READF IX -I"C:\strawberry\perl\lib\CORE" -DLOAD_MY_LIBGCC -DPARL_EXE=\"parl.exe\" -s -O2 main.c C:\strawberry\perl\bin\perl.exe file2c.pl ..\script\par.pl my_par_pl.c load_my_p ar_pl 1 gcc -c -s -O2 -DWIN32 -DHAVE_DES_FCRYPT -DUSE_SITECUSTOMIZE -DPERL_IMPLICIT_CON TEXT -DPERL_IMPLICIT_SYS -fno-strict-aliasing -mms-bitfields -DPERL_MSVCRT_READF IX -I"C:\strawberry\perl\lib\CORE" -DLOAD_MY_LIBGCC -DPARL_EXE=\"parl.exe\" -s -O2 my_par_pl.c g++ main.o my_par_pl.o win32.coff -s -s -L"C:\strawberry\perl\lib\CORE" -L"C:\ strawberry\c\lib" C:\strawberry\perl\lib\CORE\libperl512.a C:\strawberry\c\i686 -w64-mingw32\lib\libmoldname.a C:\strawberry\c\i686-w64-mingw32\lib\libkernel32. a C:\strawberry\c\i686-w64-mingw32\lib\libuser32.a C:\strawberry\c\i686-w64-ming w32\lib\libgdi32.a C:\strawberry\c\i686-w64-mingw32\lib\libwinspool.a C:\strawbe rry\c\i686-w64-mingw32\lib\libcomdlg32.a C:\strawberry\c\i686-w64-mingw32\lib\li badvapi32.a C:\strawberry\c\i686-w64-mingw32\lib\libshell32.a C:\strawberry\c\i6 86-w64-mingw32\lib\libole32.a C:\strawberry\c\i686-w64-mingw32\lib\liboleaut32.a C:\strawberry\c\i686-w64-mingw32\lib\libnetapi32.a C:\strawberry\c\i686-w64-min gw32\lib\libuuid.a C:\strawberry\c\i686-w64-mingw32\lib\libws2_32.a C:\strawberr y\c\i686-w64-mingw32\lib\libmpr.a C:\strawberry\c\i686-w64-mingw32\lib\libwinmm. a C:\strawberry\c\i686-w64-mingw32\lib\libversion.a C:\strawberry\c\i686-w64-min gw32\lib\libodbc32.a C:\strawberry\c\i686-w64-mingw32\lib\libodbccp32.a C:\straw berry\c\i686-w64-mingw32\lib\libcomctl32.a -o par.exe C:\strawberry\perl\bin\perl.exe -e1 C:\strawberry\perl\bin\perl.exe file2c.pl par.exe my_par.c load_my_par 1 30000 C:\strawberry\perl\bin\perl.exe file2c.pl C:\strawberry\perl\bin\perl512.dll my_ libperl.c load_my_libperl 1 30000 C:\strawberry\perl\bin\perl.exe file2c.pl C:\strawberry\perl\bin\libgcc_s_sjlj-1 .dll my_libgcc.c load_my_libgcc 1 30000 gcc -c -s -O2 -DWIN32 -DHAVE_DES_FCRYPT -DUSE_SITECUSTOMIZE -DPERL_IMPLICIT_CON TEXT -DPERL_IMPLICIT_SYS -fno-strict-aliasing -mms-bitfields -DPERL_MSVCRT_READF IX -I"C:\strawberry\perl\lib\CORE" -DLOAD_MY_LIBGCC -DPARL_EXE=\"parl.exe\" -s -O2 static.c static.c: In function 'main': static.c:107: warning: passing argument 3 of 'spawnvpe' from incompatible pointe r type c:\strawberry\c\bin\../lib/gcc/i686-w64-mingw32/4.4.3/../../../../i686-w64-mingw 32/include/process.h:169: note: expected 'char * const*' but argument is of type 'const char * const*' static.c:107: warning: passing argument 4 of 'spawnvpe' from incompatible pointe r type c:\strawberry\c\bin\../lib/gcc/i686-w64-mingw32/4.4.3/../../../../i686-w64-mingw 32/include/process.h:169: note: expected 'char * const*' but argument is of type 'const char * const*' g++ static.o -s -s -L"C:\strawberry\perl\lib\CORE" -L"C:\strawberry\c\lib" C: \strawberry\perl\lib\CORE\libperl512.a C:\strawberry\c\i686-w64-mingw32\lib\libm oldname.a C:\strawberry\c\i686-w64-mingw32\lib\libkernel32.a C:\strawberry\c\i68 6-w64-mingw32\lib\libuser32.a C:\strawberry\c\i686-w64-mingw32\lib\libgdi32.a C: \strawberry\c\i686-w64-mingw32\lib\libwinspool.a C:\strawberry\c\i686-w64-mingw3 2\lib\libcomdlg32.a C:\strawberry\c\i686-w64-mingw32\lib\libadvapi32.a C:\strawb erry\c\i686-w64-mingw32\lib\libshell32.a C:\strawberry\c\i686-w64-mingw32\lib\li bole32.a C:\strawberry\c\i686-w64-mingw32\lib\liboleaut32.a C:\strawberry\c\i686 -w64-mingw32\lib\libnetapi32.a C:\strawberry\c\i686-w64-mingw32\lib\libuuid.a C: \strawberry\c\i686-w64-mingw32\lib\libws2_32.a C:\strawberry\c\i686-w64-mingw32\ lib\libmpr.a C:\strawberry\c\i686-w64-mingw32\lib\libwinmm.a C:\strawberry\c\i68 6-w64-mingw32\lib\libversion.a C:\strawberry\c\i686-w64-mingw32\lib\libodbc32.a C:\strawberry\c\i686-w64-mingw32\lib\libodbccp32.a C:\strawberry\c\i686-w64-ming w32\lib\libcomctl32.a win32.coff -o static.exe C:\strawberry\perl\bin\perl.exe -e1 C:\strawberry\perl\bin\perl.exe parlsig.pl static.exe par.exe 1 30000 C:\strawberry\perl\bin\perl.exe run_with_inc.pl static.exe -I../blib/lib -q -B - O..\script\parl.exe C:\strawberry\perl\bin\perl.exe -e "chmod(oct('0600'), '..\blib\lib\PAR\Stripped PARL\Static.pm');" C:\strawberry\perl\bin\perl.exe encode_append.pl static.exe ..\blib\lib\PAR\Stri ppedPARL\Static.pm C:\strawberry\perl\bin\perl.exe -e "chmod(oct('0444'), '..\blib\lib\PAR\Stripped PARL\Static.pm');" C:\strawberry\perl\bin\perl.exe run_with_inc.pl par.exe -I../blib/lib -q -B -O.. \script\parldyn.exe C:\strawberry\perl\bin\perl.exe -e "chmod(oct('0600'), '..\blib\lib\PAR\Stripped PARL\Dynamic.pm');" C:\strawberry\perl\bin\perl.exe encode_append.pl par.exe ..\blib\lib\PAR\Strippe dPARL\Dynamic.pm C:\strawberry\perl\bin\perl.exe -e "chmod(oct('0444'), '..\blib\lib\PAR\Stripped PARL\Dynamic.pm');" dmake.EXE: Error: -- `script\parldyn.exe' not found, and can't be made RSCHUPP/PAR-Packer-1.005.tar.gz C:\strawberry\c\bin\dmake.EXE -- NOT OK Running make test Can't test without successful make Running make install Make had returned bad status, install seems impossible Failed during this command: RSCHUPP/PAR-Packer-1.005.tar.gz : make NO
Subject: Re: [rt.cpan.org #57948] Bug report: pp-generated executable and a missing dependency libgcc_s_sjlj-1.dll
Date: Sun, 06 Jun 2010 20:29:53 +0300
To: bug-PAR-Packer [...] rt.cpan.org
From: mjk [...] iki.fi
Running the installation again with force: force install PAR::Packer Seems to be able to complete the installation without errors. And the resulting executable works fine! I don't yet understand, what went wrong with the first installation round. Running the install twice seems to do the trick. -Matti
Subject: Re: [rt.cpan.org #57948] Bug report: pp-generated executable and a missing dependency libgcc_s_sjlj-1.dll
Date: Mon, 7 Jun 2010 08:04:12 +0200
To: "bug-PAR-Packer [...] rt.cpan.org" <bug-PAR-Packer [...] rt.cpan.org>
From: Roderich Schupp <roderich.schupp [...] googlemail.com>
Show quoted text
> I don't yet understand, what went wrong with the first installation > round. Running the install twice seems to do the trick
I encountered that problem, too. Running dmake twice completes the build. Looks like I broke some subtle ordering constraint in the Makefile. Cheers, Roderich
Folks, the build problems have nothing to do with the original bug. Fort iem
Folks, the build problems have nothing to do with the original bug. For the time being, follow the advice in my last entry or file a new bug report, BUT KEEP THIS BUG RESOLVED.
Please direct follow ups w.r.t. the build problem recently reported on this ticket (which is different from the original problem) to #58266