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
_______________________________________________ http://lists.gnu.org/mailman/listinfo/libtool