Thu Nov 18 04:38:06 2010: Request 63083 was acted upon.
Transaction: Correspondence added by RSCHUPP
Queue: PAR-Packer
Subject: pp: Undefined subroutine &DynaLoader::bootstrap called in
pp-compiled bianry
Broken in: 1.007
Severity: Important
Owner: Nobody
Requestors: cs...@parallel.ru
Status: open
Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=63083 >
On 2010-11-18 01:51:24, Coctic wrote:
> $ readelf -d
>
/home/users/cstef/tmp/par-cstef/cache-91983bfecf21472d244f6bf26116bc20ee4433d3/a.exe
> ...
> 0x0000000000000001 (NEEDED) Shared library: [libperl.so.5.8]
> ...
> $ ls /home/users/cstef/tmp/par-cstef/cache-
> 91983bfecf21472d244f6bf26116bc20ee4433d3/libperl*
> /home/users/cstef/tmp/par-cstef/cache-
> 91983bfecf21472d244f6bf26116bc20ee4433d3/libperl.so.5.8.8
That explains it:
- the a.exe in the cache directory (which is different from the
a.exe you actually invoked) is actually a special purpose
Perl interpreter (it's actually the same file for any
packed executable)
- since your perl (on the machine where you built PAR::Packer) is
linked against a shared libperl, the special interpreter is also
linked against this libperl
- in this case we also pack said shared libperl into the executable;
if the packed executable is run, the packed libperl is extracted
into the cache area
The problem is the name of the libperl file in the cache:
when linking, ld burned "libperl.so.5.8" into a.exe, so that's
the name the shared library loader is looking for when trying
to execute a.exe (the one in the cache area). It is run with
the cache area prepended to LD_LIBRARY_PATH, so that's where
the loader is looking first. But the file there is called
"libperl.so.5.8.8", hence it won't get considered. Next on the
loader's search path is the built-in /usr/lib where a file
called libperl.so.5.8 is actually found - but it's from perl 5.8.9
(and there exist apparently slight incompatibilities between
5.8.8 and 5.8.9 on the C level).
So we've to find out what caused the discrepancy libperl.so.5.8
vs libperl.so.5.8.8 (and perhaps improve PAR::Packer's build process
to avoid that). Can you please post the output of
perl -V
(on the machine where you built PAR::Packer)?
IIRC I've seen similar before - are you running CentOS?
Note: Your workaround confirms that the problem is indeed caused by
the "wrong" libperl.so, but it won't work in general as the
cache area is specific to the user and also specific to
the packed executable (the long checksum in the cache area name
is approximately the SHA1 of the executable itself).
