Re: DESTDIR trouble

[Bernd Jendrissek]

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?