Re: link_all_deplibs feature

[Ralf Wildenhues]

Hello Alexander,

* Alexander Leidinger wrote on Thu, Sep 06, 2007 at 10:23:32AM CEST:
>
> 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.

FYI, in GNU Libtool currently no system get link_all_deplibs set to no.
(Some distributions change this in their version; Debian for example.)
This is because link_all_deplibs=no exposes some bugs in libtool, that
are rather nontrivial to fix.  The HEAD testsuite has tests for them
in libtool/tests/indirect_deps.at (if you like I can explain the issues,
they have been reported several times).

> I would like to change this.

FWIW, before we accept the change the bugs would need to be fixed.

> 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

Have a look at the Debian diff against GNU Libtool (I can dig out a URL
for it if you like).

> 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?

See libltdl/m4/libtool.m4.

> 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?

Not sure what you mean here, but $link_all_deplibs (for the C tag)
should be valid after the AC_PROG_LIBTOOL macro has been invoked.

> 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.

Unless you link statically; or you cross-compile or have libraries in
unusual places and do not use -rpath-link or similar.

(I thought pkg-config now offers a way to list private, i.e. indirect,
libs separately?)

> 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.

Yes.  We are aware of the limitations and pain this causes for
distributions.  However, the aforementioned bugs also cause trouble for
unwary developers and users.

> 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`

To extract settings from the libtool script, use --config, e.g.:
  $LIBTOOL --config | sed -n 's/^link_all_deplibs=//p'

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

That would not work for static linking.

Hope that helps.

Cheers,
Ralf