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 _______________________________________________ http://lists.gnu.org/mailman/listinfo/libtool
