Re: Fix variables_saved_for_relink / LD_LIBRARY_PATH with libtool wrapped files

[Ralf Wildenhues]

Hi Mike,

* Mike Frysinger wrote on Mon, Dec 19, 2005 at 06:41:09AM CET:
> On Wednesday 09 November 2005 17:19, Ralf Wildenhues wrote:
> >
> >     * libltdl/m4/libtool.m4 (_LT_LINKER_SHLIBS): Move setting of
> >     `variables_saved_for_relink'..
> >     (_LT_SYS_DYNAMIC_LINKER): here, when both `shlibpath_var'
> >     and `runpath_var' have been set.
> >     Reported by Mike Frysinger <address@hidden>.
> 
> since 1.5.22 was released i was going through the patches we use with 1.5.20 
> to cut out all the unneeded stuff when i came to this issue ... seems there 
> was a bit of confusion as to what i was trying to report ...

Hmm.  Teaches me to get people to test whether their bugs are indeed
fixed.  Luckily with HEAD we can point them to the nightly tarball.

> my issue dealt with executing programs that had not yet been installed

OK.

> (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.

> 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).  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.

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

|        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'.

OTOH, on gentoo, DT_RPATH *is set*.  So, let's take a look.
echo 'int main() { return 0;} ' > a.c
gcc -c a.c
gcc -o a a.o -Wl,-rpath,/foo
objdump -p a | grep PATH
  RPATH       /foo
  RUNPATH     /foo


Aaah!  So gentoo changes GNU binutils ld behavior, but the info document
does not reflect these changes, and its libtool configuration does not
either.

> so the question was, since libtool already goes through lengths to make sure 
> the local files are used (via ELF RUNPATH tags), wouldnt adding additional 
> logic for LD_LIBRARY_PATH make sense ?

We have that logic.  We check `$shlibpath_overrides_runpath'.  The
corresponding code is

|         # Export our shlibpath_var if we have one.
|         if test "$shlibpath_overrides_runpath" = yes && test -n 
"$shlibpath_var" && test -n "$temp_rpath"; then
|           $echo >> $output "\
|     # Add our own library path to $shlibpath_var
|     $shlibpath_var=\"$temp_rpath\$$shlibpath_var\"
| 
|     # Some systems cannot cope with colon-terminated $shlibpath_var
|     # The second colon is a workaround for a bug in BeOS R4 sed
|     $shlibpath_var=\`\$echo \"X\$$shlibpath_var\" | \$Xsed -e 's/::*\$//'\`
| 
|     export $shlibpath_var
| "
|         fi

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

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.

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.  ;-)

Cheers,
Ralf