On Thu, Sep 16, 2010 at 11:37 AM, Philip Kime <[email protected]> wrote: > Thanks - I managed to work this out eventually - the problem seems to > be that on Linux where libperl.so is usually in /usr/lib, this gets > picked up by the install even if it's not the right libperl for the > perl you are building with.
Yes. The problem here is that the information in Config.pm (and Config_heavy.pl) - which is assembled when Perl itself is built - does record the fact that there ought to be a libperl.so, but not _where_ it has been installed. Or it records a libperl.so even if perl (the executable) was linked statically. So we have to guess by looking for the usual suspects. This happens esp. with self-built Perls (installed in parallel with a distro version) which might otherwise be totally fine (passed the self test, installs its modules in places different from the distro Perl etc). It happened to me when I recently built and installed Perl 5.10.1 in /usr/local/... so I could investigate some PAR problem (I regularly have Debian's 5.12.2 installed). PAR::Packer built against the /usr/local/... perl picked up the libperl.so in /usr/lib (which was from 5.12.2). I had to manually tweak Config.pm for the local installation to make PAR::Packer use the libperl.so in /usr/local/... Cheers, Roderich
