Re: Fix variables_saved_for_relink / LD_LIBRARY_PATH with libtool wrapped files

[Mike Frysinger]

On Mon, Dec 19, 2005 at 10:22:04AM +0100, Ralf Wildenhues wrote:
> * Mike Frysinger wrote on Mon, Dec 19, 2005 at 06:41:09AM CET:
> > (thus no relinking) ...
> 
> False conclusion.  Whether relinking is done for an uninstalled or an
> installed binary, depends on several different factors, one of them
> being the system.

was not aware of this ... i thought relinking was only related to the
install step and moving the files out of the builddir and into the
install paths

> > when i tested 1.5.22 and the test case i posted, it still fails :/
> > 
> > the simplified test case:
> 
> Thanks for posting the recipe.  First, note that the 4.16 tarball does
> not use libtool 1.5.22 (but I guess you knew that).

err, i must admit that i forgot about that small detail

> But even changing
> that manually, I neither get the shell wrapper to set LD_LIBRARY_PATH
> _nor_ to expose the problem.  This is on GNU/Linux Debian and FC3.
> I *can* expose the problem on Gentoo, however.

if you export LDFLAGS=-Wl,--enable-new-dtags before running configure
in both steps, you'll reproduce the problem on Debian (see below)

> So we have to be even more precise to even understand the bug here.
> Please point me to the set of patches gentoo applies to both their
> libtool, and their ld.so.  Because GNU binutils ld.so has

mmm, ld.so is part of glibc, not binutils ... put the patch you're be
interested here that makes the difference is one we use for binutils:
76_all_use-new-ld-dtags.patch

this is where we change the behavior of binutils' ld to act as if
--enable-new-dtags is specified by default

> |        The shared libraries needed by the program are searched for in 
> various
> |        places:
> | 
> |        o      (ELF only) Using the DT_RPATH dynamic section attribute of  
> the
> |               binary if present and DT_RUNPATH attribute does not exist.  
> Use
> |               of DT_RPATH is deprecated.
> | 
> |        o      Using the environment variable LD_LIBRARY_PATH.  Except if  
> the
> |               executable  is  a  setuid/setgid  binary,  in  which case it 
> is
> |               ignored.
> 
> and GNU libtool does not cause DT_RUNPATH to be set on most GNU/Linux
> systems.  But DT_RPATH is set, so it is honored before LD_LIBRARY_PATH,
> corresponding correctly to the setting of `$shlibpath_overrides_runpath'
> to `no'.

you seem to be confusing DT_RUNPATH with DT_RPATH ... libtool does
cause just DT_RPATH to be set (as can be seen on Debian systems), but
it does not cause DT_RUNPATH to also be set

> OTOH, on gentoo, DT_RPATH *is set*.  So, let's take a look.

on Gentoo, our ld forces DT_RUNPATH to be generated (since it is a 
'new' elf dtag) as well as DT_RPATH ... by default, Debian only
generates DT_RPATH

> and I would like to know whether setting
>   shlibpath_overrides_runpath=yes
> on gentoo would fix your issue.

doesnt seem to make a difference, but i may have done something wrong
here ...

> Also, I would like to know how the libtool testsuite fares on gentoo.
> Both with stock GNU libtool, and with your gentoo patches applied.  It
> *should* even expose the failure, I believe.

i dont release new ebuilds of libtool until the test suite passes :)

> On a related note, if there is sufficient interest that GNU libtool
> keeps working fine on gentoo, it would help if someone could grant me
> shell access to a gentoo box -- the one I have access to now will be
> moving away from it soon, due to certain hard-to-track-down issues
> that arise every now and then.  ;-)

Gentoo can be run just as easily in a chroot as Debian can ... i keep
chroot's of other distros around on my misc Gentoo boxes

but if you really wish, i could get you an account on one of my hosted
dev boxes ... any specific arch preference or just the same old boring
x86/amd64 ? ;)
-mike