On Sat, Jul 05, 2003 at 02:09:40PM -0400, Charles Wilson wrote: > Bernd Jendrissek wrote: > > I realise this may be an FAQ candidate, but I haven't gotten any joy out > > of google or the mail.gnu.org archives. > > > > My problem: > > > > I have, say, guile 1.4 installed, with libguile.so.9 in /usr/lib. Now > > I've tried to build guile 1.6.4 with a DESTDIR=foo install, but then > > things get linked with the guile libs *in /usr/lib*! (I think most of > > you should be familiar with the scenario.) So I have new libraries linked > > to the old ones. > > > > I have libtool 1.5 installed, and it *doesn't* work properly with DESTDIR. > > I've seen DESTDIR-related messages in the archives, but they always seem > > to wind down with "this is fixed in 1.5" or something to that effect. > > > Did you see this message? It details what IS and is NOT fixed in 1.5. > with regards to DESTDIR. > > http://mail.gnu.org/archive/html/libtool/2003-05/msg00026.html
I had seen it a while back, but I was wondering if it had been "silently" fixed in an as-yet unreleased libtool. > Other than identifying the problem, I don't really know how to correct > the remaining issue. But in this message > > http://mail.gnu.org/archive/html/libtool/2003-05/msg00022.html > > I posted a test case that demonstrates the issue; if anybody can figure > out how to fix libtool, they can test their fix with this small testcase > rather than trying to build guile. :-) Great! (Except that I have to make /usr/lib/libone.so and /usr/lib/libtwo.so symlinks to the real libs, manually.) Hmm, it doesn't even help to export LIBRARY_PATH=/tmp/relinkdemo/usr/lib. I just have to wonder how Red Hat and Debian and all the other distros build their packages. Okay, here's an interesting bit in ltmain.sh: 2631 if test "$linkmode,$pass" != "prog,link"; then 2632 vars="deplibs" 2633 else 2634 vars="compile_deplibs finalize_deplibs" 2635 fi 2636 for var in $vars dependency_libs; do 2637 # Add libraries to $var in reverse order 2638 eval tmp_libs=\"\$$var\" 2639 new_libs= 2640 for deplib in $tmp_libs; do 2641 # FIXME: Pedantically, this is the right thing to do, so 2642 # that some nasty dependency loop isn't accidentally 2643 # broken: 2644 #new_libs="$deplib $new_libs" 2645 # Pragmatically, this seems to cause very few problems in 2646 # practice: 2647 case $deplib in 2648 -L*) new_libs="$deplib $new_libs" ;; Anyway, if I apply this micro patch in destdir-relinklib-demo-1.0.1: diff -u ./libtool.borig ./libtool --- ./libtool.borig Mon Jul 7 09:14:04 2003 +++ ./libtool Mon Jul 7 11:02:59 2003 @@ -2985,7 +2985,7 @@ # Pragmatically, this seems to cause very few problems in # practice: case $deplib in - -L*) new_libs="$deplib $new_libs" ;; + -L*) new_libs="$new_libs $deplib" ;; -R*) ;; *) # And here is the reason: when a library appears more @@ -3003,11 +3003,11 @@ # using -Wl,-lname, so that libtool does not consider it # for duplicate removal. case " $specialdeplibs " in - *" $deplib "*) new_libs="$deplib $new_libs" ;; + *" $deplib "*) new_libs="$new_libs $deplib" ;; *) case " $new_libs " in *" $deplib "*) ;; - *) new_libs="$deplib $new_libs" ;; + *) new_libs="$new_libs $deplib" ;; esac ;; esac I get this: /tmp/destdir-relinklib-demo-1.0.1: LD_LIBRARY_PATH=/tmp/relinkdemo/usr/lib ldd /tmp/relinkdemo/usr/lib/libtwo.so.1.1.1 libone.so.2 => /tmp/relinkdemo/usr/lib/libone.so.2 (0x40002000) libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x40012000) libc.so.6 => /lib/libc.so.6 (0x4001a000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x80000000) Is there any reason why I shouldn't just apply this patch to my libtool? _______________________________________________ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
