[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

link_all_deplibs feature

From: Alexander Leidinger
Subject: link_all_deplibs feature
Date: Thu, 06 Sep 2007 10:23:32 +0200
User-agent: Internet Messaging Program (IMP) H3 (4.1.4) / FreeBSD-7.0


please CC me, as I didn't subscribed for just this one question...

In revision (branch-1-5) of ltdl.m4 you set libltdl_cv_sys_dlopen_deplibs to yes for DragonFlyBSD and FreeBSD. This is because the runtime linkers recursively open dependencies (libs) themself. libtool.m4 can be changed accordingly to not include recursive dependencies at link time too. This was not done. I would like to change this. I tried to come up with a patch (for the 1.5-branch), but the code in libtool.m4 is not the easiest to read. My first try failed. My second try ("big hammer"-change) succeeded in that the final libtool script has link_all_deplibs set to no instead to unknown. Can someone please explain me what the right thing to do in the following patch and what is superflous before I send it to address@hidden

Cut & paste of the patch against libtool 1.5.22:
--- libtool.m4.orig     2007-09-04 17:56:03.000000000 +0200
+++ libtool.m4  2007-09-04 18:31:20.000000000 +0200
@@ -1443,6 +1443,7 @@
   freebsd*) # from 4.6 on
+    link_all_deplibs=no
@@ -3112,9 +3113,11 @@
     _LT_AC_TAGVAR(ld_shlibs, $1)=no
+    _LT_AC_TAGVAR(link_all_deplibs, $1)=no
     _LT_AC_TAGVAR(archive_cmds_need_lc, $1)=no
   freebsd* | kfreebsd*-gnu | dragonfly*)
+    _LT_AC_TAGVAR(link_all_deplibs, $1)=no
     # FreeBSD 3 and later use GNU C++ and GNU ld with standard ELF
     # conventions
     _LT_AC_TAGVAR(ld_shlibs, $1)=yes
@@ -5895,6 +5898,7 @@
       _LT_AC_TAGVAR(hardcode_libdir_flag_spec, $1)='-R$libdir'
       _LT_AC_TAGVAR(hardcode_direct, $1)=yes
       _LT_AC_TAGVAR(hardcode_shlibpath_var, $1)=no
+      _LT_AC_TAGVAR(link_all_deplibs, $1)=no


I also had a look at the HEAD branch, as I want to provide a patch for it too, to make sure there's no regression when 2.0 is released. But I don't know where to start. The source seems to be completely restructured (I only had a look via the CVS webinterface). Can someone please point me to the right file?

I also have some questions regarding the link_all_deplibs part in libtool. Is it possible to determine in the configure script what the value of this variable is?

The reason is that a lot of libs (e.g. gnutls, pango, gtk, ...) also list the libs they are linked to in their pkg-config files. This is not necessary on systems where link_all_deplibs is set to no. If the libs are specified there regardless, a reference to the lib is added to the object file of an application which uses such a lib, even if they don't directly reference a symbol from those libs. The result of this is, that you have to unnecessary recompile the application on a change of a lib which is an indirect dependency. Currently you also can not do automatic dependency checking for package systems (on link_all_deplibs=no systems), as even indirect dependencies are recorded in the binaries. If only the direct dependencies are recorded (those which the application uses symbols from), you can do a "objdump -x binary | grep NEEDED" and compare this with the recorded dependencies in the package-system.

Visualisation of the current situation on link_all_deplibs={unknown|yes} systems:
 - logical dependency tree: libA <- libB <- appC
 - recorded libs in libB: libA
 - recorded libs in appC: libA, libB
 - superflous libs (link_all_deplibs=no) recorded in appC: libA

With a way to be able to determine in configure if the current system uses link_all_deplibs=no or not, libB could determine if it has to add libA to his libA-config script (or libA.pc file for pkg-config) or not. I can imagine a combination of grep, cut and test, but for this I need the filename of the libtool script used, e.g.:
deplibs_required=`grep link_all_deplibs= $LIBTOOL | cut -d = -f 2`

With something like this one could do:
if test $deplibs_requiered != no; then


I have seen the Great Pretender and he is not what he seems.    Alexander @ PGP ID = B0063FE7       netchild @  : PGP ID = 72077137

reply via email to

[Prev in Thread] Current Thread [Next in Thread]