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

[Corey Minyard]

On Mon, Sep 05, 2022 at 02:27:03AM +0200, Vincent Lefevre wrote:
> On 2022-09-04 12:21:58 -0500, Corey Minyard wrote:
> [...]
> > I haven't figured out why, and I can't find a way to force libtool to
> > put in the LD_LIBRARY_PATH.  What am I doing wrong?
> 
> Look at the line "shlibpath_overrides_runpath=" in the generated
> libtool script. I suspect that you have "yes" in one case and
> "no" in the other case. If I understand correctly, the decision
> is hardcoded in "libtool.m4".

Yes, you are correct.  I looked at the code that checks for this, and it
appears that the issue has to do with toolchain settings.

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.

Thank you,

-corey

> 
> -- 
> Vincent Lefèvre <vincent@vinc17.net> - Web: <https://www.vinc17.net/>
> 100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
> Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)