On Thu, Sep 24, 2009 at 8:38 PM, Jonathan Robinson <jonarobin...@rim.com> wrote: > RPATH is indeed pointing at a directory which exists on the client machine: > Tag Type Name/Value > 0x00000001 (NEEDED) Shared library: [libresolv.so.2] > 0x00000001 (NEEDED) Shared library: [libnsl.so.1] > 0x00000001 (NEEDED) Shared library: [libdl.so.2] > 0x00000001 (NEEDED) Shared library: [libm.so.6] > 0x00000001 (NEEDED) Shared library: [libcrypt.so.1] > 0x00000001 (NEEDED) Shared library: [libutil.so.1] > 0x00000001 (NEEDED) Shared library: [libpthread.so.0] > 0x00000001 (NEEDED) Shared library: [libc.so.6] > 0x0000000f (RPATH) Library rpath: > [/usr/lib/perl5/5.8.5/i386-linux-thread-multi/CORE] > 0x0000000c (INIT) 0x8049a10 > 0x0000000d (FINI) 0x804d260
Indeed, same problem as in this thread http://www.nntp.perl.org/group/perl.par/2009/06/msg4103.html Symptoms are: - RPATH, but _not_ RUNPATH (hence RPATH takes precedence of $LD_LIBRARY_PATH) - RPATH points to something that exists on client > In the provided thread I was unable to decipher your solution. Could you > please explain how to fix this? No fix yet. I took a stab at it (not mentioned in the thread), but failed. Actually it's not PAR::Packer that's broken, but the configuration on the build machine (a correctly configured system would show both RUNPATH and RPATH above). But we already do workarounds for other broken systems :) The culprit is the special purpose Perl interpreter that is contained in every packed executable. You can find it after running the executable at least once, because it gets extracted into /tmp/par-USER/cache-CHECKSUM with the same name as the packed executable (but it's always the same file). We want to get rid of any RUNPATH/RPATH on this executable. Unfortunately this executable is invoked when building PAR::Packer and is also used by parl. In both these cases RUNPATH/RPATH _is_necessary. So far, I haven't come up with a solution for this paradox. Cheers, Roderich
