Wed Aug 06 07:19:31 2008: Request 38217 was acted upon.
Transaction: Correspondence added by [EMAIL PROTECTED]
Queue: PAR
Subject: Re: [rt.cpan.org #38217] script looking for libperl.so.5.8, but
libperl.so.5.8.8 exists
Broken in: (no value)
Severity: Normal
Owner: Nobody
Requestors: [EMAIL PROTECTED]
Status: new
Ticket <URL: http://rt.cpan.org/Ticket/Display.html?id=38217 >
> correction: the executable was build on ubuntu 8.04, then run on
> systemrescuecd, Fedora 8 Live , grml, puppy-4.00, CentOS-5.2,
> openSUSE-11.0 - all of them need the workaround with renaming.
Did you build PAR::Packer yourself or installed it from a distro package?
What's probably happend here: When building PAR::Packer it
looks for the shared perl library and apparently found
/usr/lib/libperl.so.5.8.8.
It added it *under this name* into the proto-packed executable (which
becomes a part of any "real" PAR-packed executable), hence that is the
name which is also used for extraction. Now the proto-packed executable also
contains a custom Perl interpreter, linked against said shared library.
But it references (and looks for at runtime) the internal soname of the
library which is most likely libperl.so.5.8.
Looking at the Ubuntu packages I see a possible scenario how this might
happen when building PAR:Packer and package libperl5.8_5.8.8-12
is installed, but libperl-dev_5.8.8-12 is *not* installed:
- perl_5.8.8-12 has Config{libperl}="libperl.so.5.8.8"
- find_file in myldr/Makefile.PL first looks for libperl.so (via
DynaLoader::dl_findfile),
but doesn't find it (because the symlink /usr/lib/libperl.so is contained
in package libperl-dev_5.8.8-12 which isn't installed)
- find_file now tries to locate $Config{libperl} in several directories,
finds /usr/lib/libperl.so.5.8.8 and returns that
If libperl-dev_5.8.8-12 had been installed, find_file would have found
/usr/lib/libperl.so,
resolved that symlink (once) to /usr/lib/libperl.so.5.8 and used that -
that would have worked. But this strategy is also fragile: Why resolve
only one level of symlinks - after all (in this case)
/usr/lib/libperl.so.5.8 is
also a symlink (to /usr/lib/libperl.so.5.8.8) which wouldn't have worked.
What if /usr/lib/libperl.so hat directly resolved to /usr/lib/libperl.so.5.8.8?
The real solution would be to look for the shared library file (because it has
to be included in the proto-executable), but as extraction name use whatever
the platform linker stores in the custom Perl interpreter when linking it.
However that is highly platform dependent...
The alternative would be to link a static version of libperl, but that might
not be readily available in your Perl installation.
Cheers, Roderich
