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
