Well, I think I've solved it! Due to compatibility issues with the application I'm writing, it happens to be 32-bit. On FreeBSD, there are TWO forms for setting LD* related ENV VARS. In particular, the one I need is LD_LIBRARY_PATH versus LD_32_LIBRARY_PATH!
I'm able to prove this by running with PAR_GLOBAL_CLEAN=0, seeing my failure case (along with discovering the cache dir) and then re-running with LD_32_LIBRARY_PATH set to my cache dir, which results in success. It looks to me like adding LD_32_LIBRARY_PATH to the ld_path_keys in myldr/mktmpdir.c might just fix this up for me ;-) Now, in the simplest form, here's what I've discovered and what I'm going to explicitly control regarding library search orders: 1. ld.so looks for embedded paths in the SO and searches those paths first 2. Next, LD_LIBRARY_PATH (or equivalent) is searched 3. Finally, default OS Level paths are examined As Roderich mentioned in the first response, PAR::Packer is setting LD_LIBRARY_PATH(s), which is as high in the stack that PAR::Packer (or anyone else for that matter) can get during execution time. The end result for me is that I am compiling the "shim" shared libraries that reference 3rd party components. Which means, I can control what get's embedded in the SO. I haven't been doing that to this point which is why the linux strace showed paths prior to par-user/cache being searched. Thanks for the info and direction on helping to solve this. -Tim On Thu, Aug 23, 2012 at 3:07 AM, Roderich Schupp < roderich.sch...@googlemail.com> wrote: > > What I don't see here that IS in your's is the RPATH. I think that > *should* > > be ok. > > Yes. In fact, the RPATH in my sample shouldn't be there. I know where > it came from - my $Config{ccdlflags}. It's there to pick up the shared > libperl > (typically called libperl*.so) from its installed path. But we pack > libperl into > the packed executable and want this copy to be used, not anything picked up > from the system where the executable runs. > > > 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. > > The problem may be in the fine print. E.g. there's a subtle difference > between RPATH and RUNPATH. Maybe there's interference by some > security framework? E.g. on newer (i.e. ELF-based) HPUX, an > executable has to be specially marked so that LD_LIBRARY_PATH > will be considered at all. > > > If I'm missing something from your explanation or if there's something > odd > > in my example, please let me know. > > Nope, I'm as puzzled as you. > > Cheers, Roderich >