Re: link_all_deplibs feature

[Alexander Leidinger]

Quoting Ralf Wildenhues <address@hidden> (Fri, 7 Sep 2007 14:56:46 +0200):

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

That would be nice. I could determine if there's something which
affects FreeBSD or not.

> > I would like to change this.  
> 
> FWIW, before we accept the change the bugs would need to be fixed.

Sure.

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

You mean http://people.debian.org/~keybuk/keybuk-linux-deplibs.patch ?

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

Thanks, I will have a look.

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

Great. I give it a try.

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

Where we would get the most benefit (large packages like GNOME/KDE/...)
static linking doesn't really make sense. Apart from this, aren't
the .la files supposed to handle this recursive resolving when libtool
is used to link? Ok, there exist software out there which don't uses
libtool.

I assume non-standard lib directories means directories which are not
known to ldconfig. What's the specific error case we are talking about?

Regarding cross-compiling... this is a special case, and whoever
cross-compiles without using the cross-compiler the right way is
misusing his tools and deserves an error. I can understand that you get
complains from users which misuse the tools, maybe you can maybe print
a notice/warning at configure time if the host-arch/type/os is not the
target-arch/type/os.

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

I didn't know about this, I will have a look. Thanks for mentioning.

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

If I got it right above, I wouldn't call this a bug (see above).

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

LIBTOOL is set in configure to '$(SHELL) $(top_builddir)/libtool', this
means it's generated by configure. At which point does it exists? After
calling the AC_PROG_LIBTOOL macro, or at the end when the file.in ->
file generation takes place? If you don't know by heart, I will make a
test.

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

See above (.la files). Apart from that, one could at least test if
static libs are created or not and behave accordingly.

Do you have an idea how relevant static linking for complex software
(where there are more than one level of library dependencies) is
nowadays (except for embedded systems, where a lot is done by hand
anyway)?

Bye,
Alexander.

-- 
Vulcans do not approve of violence.
                -- Spock, "Journey to Babel", stardate 3842.4
http://www.Leidinger.net  Alexander @ Leidinger.net: PGP ID = B0063FE7
http://www.FreeBSD.org     netchild @ FreeBSD.org  : PGP ID = 72077137