[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Corey Minyard
Subject: Re: LD_LIBRARY_PATH set by wrapper on Ubuntu, not on Rocky (Redhat)
Date: Sun, 4 Sep 2022 20:52:07 -0500

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,


> -- 
> Vincent Lefèvre <> - Web: <>
> 100% accessible validated (X)HTML - Blog: <>
> Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

reply via email to

[Prev in Thread] Current Thread [Next in Thread]