Thanks for the pointers Roderich.

The key information you provided was that "the packed (and extracted)
libraries should come FIRST in the search, BEFORE the system libraries."  I
 was hoping that should be the case.

I did run through what you provided below and the results seem to be what
you probably expected.

$ pp -o show-path.freebsd -e 'print
"LD_LIBRARY_PATH=$ENV{LD_LIBRARY_PATH}\n"; \
print "LIBPATH=$ENV{LIBPATH}\n"; \
print "DYLD_LIBRARY_PATH=$ENV{DYLD_LIBRARY_PATH}\n"; \
print "SHLIB_PATH=$ENV{SHLIB_PATH}\n";'

I added the other ENV vars to be able to check additional platforms (via
different EXE's of course).

$ ./show-path.freebsd
LD_LIBRARY_PATH=/var/tmp//par-74686f6b65/cache-272e20b9352ee16cba84d0537a3c27c11e480318
LIBPATH=/var/tmp//par-74686f6b65/cache-272e20b9352ee16cba84d0537a3c27c11e480318
DYLD_LIBRARY_PATH=/var/tmp//par-74686f6b65/cache-272e20b9352ee16cba84d0537a3c27c11e480318
SHLIB_PATH=/var/tmp//par-74686f6b65/cache-272e20b9352ee16cba84d0537a3c27c11e480318

I did confirm with 'man ld.so' that on FreeBSD does use LD_LIBRARY_PATH.


$ readelf -d
/var/tmp//par-726f6f74/cache-272e20b9352ee16cba84d0537a3c27c11e480318/show-path.freebsd6.0

Dynamic segment at offset 0x121438 contains 23 entries:
  Tag        Type                         Name/Value
 0x00000001 (NEEDED)                     Shared library: [libm.so.4]
 0x00000001 (NEEDED)                     Shared library: [libcrypt.so.3]
 0x00000001 (NEEDED)                     Shared library: [libpthread.so.2]
 0x00000001 (NEEDED)                     Shared library: [libc.so.6]
 0x0000000c (INIT)                       0x805b9f8
 0x0000000d (FINI)                       0x81457f4
 0x00000004 (HASH)                       0x80480ec
 0x00000005 (STRTAB)                     0x8052b34
 0x00000006 (SYMTAB)                     0x804afe4
 0x0000000a (STRSZ)                      30586 (bytes)
 0x0000000b (SYMENT)                     16 (bytes)
 0x00000015 (DEBUG)                      0x0
 0x00000003 (PLTGOT)                     0x8169530
 0x00000002 (PLTRELSZ)                   1936 (bytes)
 0x00000014 (PLTREL)                     REL
 0x00000017 (JMPREL)                     0x805b268
 0x00000011 (REL)                        0x805b238
 0x00000012 (RELSZ)                      48 (bytes)
 0x00000013 (RELENT)                     8 (bytes)
 0x6ffffffe (VERNEED)                    0x805b218
 0x6fffffff (VERNEEDNUM)                 1
 0x6ffffff0 (VERSYM)                     0x805a2ae
 0x00000000 (NULL)                       0x0

What I don't see here that IS in your's is the RPATH.  I think that
*should* be ok.

So, in my problematic case, I suspect it's a matter of how the glue lib
(Net/SSLeay.so) is being built and the resulting RPATH that get's embedded.

I would expect that in the PAR::Packer case, just like anything else, ld.so
is going to look for a few embedded clues (e.g. RPATH) and use those paths
first, then it'll start looking at "system" paths, including
LD_LIBRARY_PATH settings.

I'll look more at how all my components are compiled and see if some
embedded RPATH (or other setting) is maybe what's causing my issues.

If I'm missing something from your explanation or if there's something odd
in my example, please let me know.

Thanks!
-Tim

On Wed, Aug 22, 2012 at 2:17 AM, Roderich Schupp <
roderich.sch...@googlemail.com> wrote:

> Hi Tim,
>
> On Tue, Aug 21, 2012 at 6:11 PM, Tim Hoke <th...@northpeak.org> 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
>

Reply via email to