Re: Fix variables_saved_for_relink / LD_LIBRARY_PATH with libtool wrapped files

[Mike Frysinger]

On Wednesday 09 November 2005 17:19, Ralf Wildenhues wrote:
> * Ralf Wildenhues wrote on Sun, Nov 06, 2005 at 07:40:19PM CET:
> > OK to apply to branch-1-5 and forward-port?
>
> Applied to branch-1-5 and HEAD, the forward-port is below.
>
>       * 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 ...

my issue dealt with executing programs that had not yet been installed (thus 
no relinking) ... when i tested 1.5.22 and the test case i posted, it still 
fails :/

the simplified test case:
wget http://gentoo.osuosl.org/distfiles/file-4.12.tar.gz
tar zxf file-4.12.tar.gz
cd file-4.12
./configure
make
cd ..
wget http://gentoo.osuosl.org/distfiles/file-4.16.tar.gz
tar zxf file-4.16.tar.gz
cd file-4.16
./configure
make
cd magic
make clean
LD_LIBRARY_PATH=../../file-4.12/src/.libs make

here it will fail because when the code in the magic subdir attempts to 
execute ../src/file, it will load up the libmagic from the 4.12 dir instead 
of the 4.16 dir

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 ?

patch:
http://lists.gnu.org/archive/html/libtool/2005-09/txt41NJtyNbEM.txt
original post:
http://lists.gnu.org/archive/html/libtool/2005-09/msg00053.html
-mike