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
>

Reply via email to