Re: LD_LIBRARY_PATH set by wrapper on Ubuntu, not on Rocky (Redhat)

[Corey Minyard]

On Mon, Sep 05, 2022 at 04:35:43AM +0200, Vincent Lefevre wrote:
> On 2022-09-04 20:52:07 -0500, Corey Minyard wrote:
> > It compiles a program with -rpath and expects to see the set rpath
> > appear after RUNPATH.  On the system that works:
> > 
> >   $ gcc -o hello hello.c -Wl,-rpath -Wl,/foo
> >   $ objdump -p hello | grep RUNPATH
> >     RUNPATH              /foo
> > 
> > However, on the system that doesn't work:
> > 
> >   $ gcc -o hello hello.c -Wl,-rpath -Wl,/foo
> >   $ objdump -p hello | grep RUNPATH
> >   $ objdump -p hello | grep foo
> >     RPATH                /foo
> > 
> > Doing a little research, it looks like RPATH overrides LD_LIBRARY_PATH
> > which overrides RUNPATH.  Well, ok, so the whole relinking thing is
> > required in the RPATH.
> > 
> > However, in order for dlopen-ed modules to work per the libtool
> > documentation, LD_LIBRARY_PATH should still be set, even if -rpath
> > overrides it.  There's no reason to not set it, is there?
> > 
> > Outside of that, it looks like I can work around this by adding
> > LDFLAGS="$LDFLAGS -Wl,--enable-new-dtags"
> > before LT_INIT.
> 
> If the wrapper doesn't touch LD_LIBRARY_PATH, you'd rather need
> LDFLAGS="$LDFLAGS -Wl,--disable-new-dtags" so that the user's
> LD_LIBRARY_PATH will not get in the way (--disable-new-dtags
> makes the runpath override LD_LIBRARY_PATH). This is what I've
> done for MPFR (where we do not generate wrappers, so that
> LD_LIBRARY_PATH cannot be "fixed").

--enable-new-dtags causes LD_LIBRARY_PATH to override runpath (it uses
RUNPATH instead of RPATH), which then causes libtool to add all the
.libs directories to the LD_LIBRARY_PATH, which is exactly what I want.

I don't care, actually, if LD_LIBRARY_PATH overrides runpath or not.  I
just want the LD_LIBRARY_PATH set like the documentation says it will be
set so the code can find the modules.

I should probably file a bug on that.  Thanks for your help.

-corey