Hi Tim,
On Tue, Aug 21, 2012 at 6:11 PM, Tim Hoke <[email protected]> wrote:
> What's going on with FreeBSD compared to others? Is there some magic I can
> invoke to control the shared library path loading order and locations?
No, PAR::Packer should have done that for you. Note that your strace
for RHEL also shows incorrect behaviour (though the search for libssl
eventually succeeds): the packed (and extracted) libraries should come
FIRST in the search, BEFORE the system libraries.
Can you check the setting of LD_LIBRARY_PATH for a packed executable
(assuming that FreeBSD uses LD_LIBRARY_PATH for the
search path for shared libraries):
$ pp -o show-path.exe -e 'print "LD_LIBRARY_PATH=$ENV{LD_LIBRARY_PATH}\n";'
$ ./show-path.exe
LD_LIBRARY_PATH=/tmp/par-user/cache-4631c3f3001de1fe9763584faea848e820073e66
Also check the custom Perl interpreter: in the above example
the cache directory
/tmp/par-user/cache-4631c3f3001de1fe9763584faea848e820073e66
should contain a file named show-path.exe (i.e. the same name as your
packed executable); please run readelf on it:
$ readelf -d
/tmp/par-ccm_root/cache-1ad335c61a0de3ec3f1947d87dbd4ab04eb02f06/show-path.exe
Dynamic section at offset 0x8638 contains 27 entries:
Tag Type Name/Value
0x0000000000000001 (NEEDED) Shared library: [libperl.so]
0x0000000000000001 (NEEDED) Shared library: [libm.so.6]
0x0000000000000001 (NEEDED) Shared library: [libdl.so.2]
0x0000000000000001 (NEEDED) Shared library: [libcrypt.so.1]
0x0000000000000001 (NEEDED) Shared library: [libpthread.so.0]
0x0000000000000001 (NEEDED) Shared library: [libc.so.6]
0x000000000000000f (RPATH) Library rpath:
[/usr/lib/perl5/5.8.8/x86_64-linux-thread-multi/CORE]
0x000000000000001d (RUNPATH) Library runpath:
[/usr/lib/perl5/5.8.8/x86_64-linux-thread-multi/CORE]
...
Cheers, Roderich