Mon May 10 14:44:37 2010: Request 57272 was acted upon.
Transaction: Correspondence added by CSJEWELL
Queue: PAR-Packer
Subject: Error building on Strawberry 5.12.0.1 32-bit (can't find
script/parl.exe)
Broken in: (no value)
Severity: Important
Owner: RSCHUPP
Requestors: csjew...@cpan.org
Status: open
Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=57272 >
On Mon May 10 05:15:10 2010, RSCHUPP wrote:
> On Sat May 08 15:00:13 2010, CSJEWELL wrote:
> > The earlier problem must have been a blip (sorry for the aggressive
> > reporting), but it was a blip hiding a test issue:
> ...
> > The problem is that gcc 4.x-compiled versions of Perl on Win32,
> > including 5.12+ and greater versions of Strawberry Perl, have to use a
> > gcc exception-handling DLL. Even the otherwise-static
> > lib\core\libperl512.a has code that uses this dll, if I'm not mistaken.
>
> Is that DLL needed for _every_ gcc compiled executable?
> Note that a pp-packed executable is actually a stub with
> a PAR archive tacked on. The stub itself is an executable built
> by PAR::Packer. It contains another executable which is
> a special purpose Perl interpreter; this executable is extracted
> by the stub (along with some DLLs and core Perl modules) into
> a temporary directory and then run.
> If the sub itself needs the DLL that means you can't
> execute the stub on a machine that hasn't the DLL installed
> (and there's no workaround, sorry). OTOH, if the stub runs fine
> and it's just the extracted Perl interpreter that needs the DLL
> then adding the DLL to the pp command line will
> do the trick. I'd prefer to do that automatically, if someone
It's needed for every *non-C* compiled executable or library, as far as
I can tell. Perl itself includes some C++ code on Win32, (see the
CPerlHost class in
http://cpansearch.perl.org/src/JESSE/perl-5.12.0/win32/perlhost.h) so
the library is required for it.
I just checked (I had a script that I wanted to try it with) - your
stubs work (I renamed the two dll copies to .old and the compiled
executable still worked), but parl(dyn)?.exe needs the .dll. [I assume
that parl(dyn)?.exe is your specialized perl.] So adding the .dll to the
command line should make things work.
> can tell me how to find out whether the Perl running the pp script
> is actually a Strawberry Perl.
The way to detect Strawberry itself (at least for the past 6 months)
absolutely and uniquely is $Config{myuname} =~ m{\AWin32 [ ] strawberry}msx.
But note that it still has to be compiled with gcc 4.x.x in order for
the library to be required. While this may be unique to Strawberry
5.12.x right now, it may not be in the future, so I wouldn't go that route.
The route I would go instead is to try to detect a gcc 4.x.x-compiled
perl that had the library in its directory (because they'd have to
include the library itself in order to run.) The rationale being along
the lines of "detect the capability that Strawberry is using, rather
than detecting Strawberry itself."
That detection sequence would be:
1) $^] > 5.011
# They added the ability to compile w/ GCC 4.x.x for Win32 in 5.11.1, so
a comparison on $^] here will short-circuit older versions quickly.
Previous versions would fail miserably in 'dmake test'.
2) and 'MSWin32' eq $^O
# This is true, and this library is needed, even for 64-bit versions of
the Perl interpreter, as long as it runs in a Windows environment, so we
aren't being more specific and using $Config{archname}. You may
eventually wish to check with somebody with a Cygwin perl and gcc 4.x.x
to see if they need to include a libgcc_*.so, as well.
3) and $Config{cc} =~ m{(?:[^a-z])?g(?:cc|\+\+)}imsx
# To detect gcc or g++. This should work even if the host triplet is in
the name.
4) and defined $Config{gccversion} and eval { $Config{gccversion} =~
m{\A(\d*) [.]}msx; my $test_gcc_version = (((defined $1) and ($1 >= 4))
? 1 : 0); $test_gcc_version; }
# to detect gcc 4.x.x or greater.
5) and a 'libgcc_*.' . $Config{so} file exists in the same directory as
'perl5*.' . $Config{so}
# This step verifies that $Config isn't lying to us about #4, and is
generalized so that if it turns out that Cygwin needs this, the code
already supports that.)
The file found in step 5 would need included. (The reason I say libgcc_*
is that there are multiple options for names for this .dll that do the
same functionality in different ways.)
It's a long chain of conditions, but that's how I'd handle it. This
would even detect self-compiled perl interpreters that would need this.
--Curtis
