Re: removal of .la files from Debian and a possible solution to the libtool shared libs problem

[Anssi Hannula]

Ralf Wildenhues wrote:
> * Anssi Hannula wrote on Wed, Aug 26, 2009 at 12:05:22PM CEST:
>> Ralf Wildenhues wrote:
>>> Do dlopen'ed modules that have indirect
>>> dependencies outside of default-searched library paths get loaded
>>> correctly now, with DT_RPATH entries only pointing to direct deplibs
>>> (and recursively for their DT_RPATH entries)?
>> This works fine without linking in dependency_libs. I continue the test
>> from my earlier message:
> 
> What I would like to see is this test (written without using libtool,
> sorry, I haven't gone through your test):
> 
[...]
> And trying that out now, I see that while this doesn't work, it works as
> soon as you replace
>   -Wl,-rpath,c
> with
>   -Wl,-rpath,`pwd`/c
> in the line creating liba.so.0.  Nice.

Yes, relative paths here are resolved against current directory, not the
library location. But you can use $ORIGIN here, it is expanded to the
library location by dynamic linker:
-Wl,-rpath,\$ORIGIN/c

>>>> Support for indirect dependencies should be a configure option so
>>>> that it should be specifically requested.
>>> See $link_all_deplibs (which is "no" on Debian but "yes" in FSF
>>> Libtool).
>> IIRC link_all_deplibs only affects executables, not libraries.
>>
>> The comment describing link_all_deplibs seems to agree:
>> # Whether libtool must link a program against all its dependency libraries.
> 
> The code in ltmain.sh doesn't agree, however.  And IIUC then Debian
> wouldn't want libraries to link against their indirect deplibs either,
> as that would still make the problem set too big for them.

I did some testing with libtool 2.2.6a:

With link_all_deplibs=yes
- library is linked against dependency_libs of the libraries it is
linked against
- executable is linked against dependency_libs of the libraries it is
linked against, and the dependency_libs of those libs are parsed recursively

With link_all_deplibs=no:
- libraries behave the same as above
- executable behaves the same as above, except the linking order is
different; it seem the recursive libs are added later in the process

With link_all_deplibs=yes + attached debian deplib_binary.patch:
- library is *not* linked against dependency_libs of the libraries it is
linked against
- executable is linked against those libs that are in dependency_libs of
the libraries it is linked against, but they are *not* processed recursively

With link_all_deplibs=no + attached debian deplib_binary.patch:
- library is *not* linked against dependency_libs of the libraries it is
linked against (same as above)
- executable is *not* linked against dependency_libs of the libraries it
is linked against

Trying to link a program statically with link_all_deplibs=no +
deplib_binary.patch still works (all dependencies are linked in
recursively). However, as you can see above, link_all_deplibs=yes no
longer produces the expected results with the patch (all libs should be
linked in recursively, as with static linking; as far as I understand
it). Note also that link_all_deplibs does not seem to make any
meaningful difference without any debian patches; it just changes
linking order.

Debian also contains the attached link_all_deplibs patch; however, it
seems buggy and breaks static linking (deps not linked in recursively).
As everything seems to work the debian way without it already (i.e. with
deplib_binary.patch only), I guess it is an earlier attempt to fix this
problem, but just not removed after the better deplib_binary.patch was
added. Its effect in the above cases is that in link_all_deplibs=no, the
recursive deps are not added, only the immediate indirect dependencies
from .la files (i.e. same behaviour as with linking libraries).

Note also that link_all_deplibs=no/yes seems to only affect programs,
just as the comment said.

Looking at the above cases, it seems libtool doesn't link libraries
recursively in any case, even without patches/changes. It just links in
the immediate dependencies from .la files. This seems rather strange to
me; it'd make sense to either not link indirect dependencies at all, or
link all of them recursively; why link with only the first indirect
dependencies?

-- 
Anssi Hannula

Index: libtool-2.2.6a/libltdl/config/ltmain.m4sh
===================================================================
--- libtool-2.2.6a.orig/libltdl/config/ltmain.m4sh      2009-04-06 
23:08:48.000000000 +0200
+++ libtool-2.2.6a/libltdl/config/ltmain.m4sh   2009-04-06 23:15:32.000000000 
+0200
@@ -4905,19 +4905,19 @@
            # It is a libtool convenience library, so add in its objects.
            convenience="$convenience $ladir/$objdir/$old_library"
            old_convenience="$old_convenience $ladir/$objdir/$old_library"
+           tmp_libs=
+           for deplib in $dependency_libs; do
+             deplibs="$deplib $deplibs"
+             if $opt_duplicate_deps ; then
+               case "$tmp_libs " in
+               *" $deplib "*) specialdeplibs="$specialdeplibs $deplib" ;;
+               esac
+             fi
+             tmp_libs="$tmp_libs $deplib"
+           done
          elif test "$linkmode" != prog && test "$linkmode" != lib; then
            func_fatal_error "\`$lib' is not a convenience library"
          fi
-         tmp_libs=
-         for deplib in $dependency_libs; do
-           deplibs="$deplib $deplibs"
-           if $opt_duplicate_deps ; then
-             case "$tmp_libs " in
-             *" $deplib "*) specialdeplibs="$specialdeplibs $deplib" ;;
-             esac
-           fi
-           tmp_libs="$tmp_libs $deplib"
-         done
          continue
        fi # $pass = conv
 

## Do not link against deplibs.  This is not needed for shared libs
## on atleast ELF systems since those already know which libs they
## need themself.  This seems to break a few things and will be fixed
## in a better way in a future upstream version.

Index: libtool-2.2.6a/libltdl/config/ltmain.m4sh
===================================================================
--- libtool-2.2.6a.orig/libltdl/config/ltmain.m4sh      2009-04-07 
19:45:25.000000000 +0200
+++ libtool-2.2.6a/libltdl/config/ltmain.m4sh   2009-04-07 23:32:35.000000000 
+0200
@@ -4591,7 +4591,10 @@
        case $pass in
        dlopen) libs="$dlfiles" ;;
        dlpreopen) libs="$dlprefiles" ;;
-       link) libs="$deplibs %DEPLIBS% $dependency_libs" ;;
+       link)
+         libs="$deplibs %DEPLIBS%"
+         test "X$link_all_deplibs" != Xno && libs="$libs $dependency_libs"
+         ;;
        esac
       fi
       if test "$linkmode,$pass" = "lib,dlpreopen"; then
Index: libtool-2.2.6a/libltdl/m4/libtool.m4
===================================================================
--- libtool-2.2.6a.orig/libltdl/m4/libtool.m4   2009-04-07 19:45:25.000000000 
+0200
+++ libtool-2.2.6a/libltdl/m4/libtool.m4        2009-04-07 23:32:35.000000000 
+0200
@@ -4182,6 +4182,9 @@
   cygwin* | mingw* | cegcc*)
     _LT_TAGVAR(export_symbols_cmds, $1)='$NM $libobjs $convenience | 
$global_symbol_pipe | $SED -e '\''/^[[BCDGRS]][[ ]]/s/.*[[ ]]\([[^ ]]*\)/\1 
DATA/;/^.*[[ ]]__nm__/s/^.*[[ ]]__nm__\([[^ ]]*\)[[ ]][[^ ]]*/\1 DATA/;/^I[[ 
]]/d;/^[[AITW]][[ ]]/s/.* //'\'' | sort | uniq > $export_symbols'
   ;;
+  linux* | k*bsd*-gnu)
+    _LT_TAGVAR(link_all_deplibs, $1)=no
+  ;;
   *)
     _LT_TAGVAR(export_symbols_cmds, $1)='$NM $libobjs $convenience | 
$global_symbol_pipe | $SED '\''s/.* //'\'' | sort | uniq > $export_symbols'
   ;;
@@ -4246,6 +4249,9 @@
   openbsd*)
     with_gnu_ld=no
     ;;
+  linux* | k*bsd*-gnu)
+    _LT_TAGVAR(link_all_deplibs, $1)=no
+    ;;
   esac
 
   _LT_TAGVAR(ld_shlibs, $1)=yes
@@ -4603,6 +4609,7 @@
        if test "$aix_use_runtimelinking" = yes; then
          shared_flag="$shared_flag "'${wl}-G'
        fi
+       _LT_TAGVAR(link_all_deplibs, $1)=no
       else
        # not using gcc
        if test "$host_cpu" = ia64; then