link_all_deplibs feature

[Alexander Leidinger]

Hi,

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

In revision 1.47.2.12 (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:
---snip---
--- 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
     shlibpath_overrides_runpath=yes
     hardcode_into_libs=yes
+    link_all_deplibs=no
     ;;
   esac
   ;;
@@ -3112,9 +3113,11 @@
     _LT_AC_TAGVAR(ld_shlibs, $1)=no
     ;;
   freebsd-elf*)
+    _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
       ;;

     hpux9*)
---snip---

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.:
---snip---
LIBTOOL=???
deplibs_required=`grep link_all_deplibs= $LIBTOOL | cut -d = -f 2`
---snip---

With something like this one could do:
---snip---
if test $deplibs_requiered != no; then
    PKGCONFIG_DEPLIBS=-lA
fi
---snip---

Bye,
Alexander.

--
I have seen the Great Pretender and he is not what he seems.

http://www.Leidinger.net    Alexander @ Leidinger.net: PGP ID = B0063FE7
http://www.FreeBSD.org       netchild @ FreeBSD.org  : PGP ID = 72077137