Re: Reducing dependency_libs to what was on the command line.

[Ralf Wildenhues]

Hi Kurt,

* Kurt Roeckx wrote on Mon, Dec 05, 2005 at 12:52:55AM CET:
> 
> As some of you might know, Debian has a patch to reduce the
> number of libraries that libtool will link too.

Yes.  And it's a support nightmare, not only for Debian Libtool,
but for us as well, because people do not recognize it's the Debian
changes that break their builds.

When I have time, I'd like to fix your current issues with it,
namely cross-compilation[1], and wrong-libs-for-uninstalled-programs[2].

And also, I very very much would like to change the way this is enabled,
in order to both
- make this usable for non-Debianers
- not unconditionally turn this on for unsuspecting Debian users

I've laid out more detailed ideas in [3].

It would be very helpful if the Debian community could agree to some
solution -- maybe something like: your build infrastructure sets an
environment variable to turn off linking against all deplibs.  I'm
willing to accept changes that would make enabling this for Debian
builds an easy O(1) operation (i.e., not changes in every package,
although that would actually be The Right Thing[3]).

And then we change link_all_deplibs to linker_needs_all_deplibs and set
that to no for any instance of GNU ld, but we also either
- disregard it for cross-compilation, or, even better
- walk the dependency tree manually for cross-compilation

Please.  link_all_deplibs=no on Debian has cost us several support
mails, and false accusations and lost credibility in GNU Libtool.

> And now I'd like to reduce it even more.

> What an other problem is that in case of convience libraries, it
> also adds all the libraries in the dependency_libs to the
> depends, and so links with all of those.  It should however only
> link with those they tried to link the convience library with,
> and not all it's dependency.

I don't understand.  Please post an example that exposes this change.

> The best solution I can see for this is to only have the
> libraries that were on the command line end up in the
> dependency_libs on the .la file, atleast for convience libraries.
> 
> I've been experimenting a little with this, and it seems to be
> giving very good results so far.

I need an example to be able to even understand the problem.

> An other problem we've expierenced in the past is that in case we
> remove some lib in the chain, all libraries that got (inderectly)
> linked to it needed to be rebuild to remove the library from their
> dependency_libs in their .la files.  Having all the libraries you
> need to link to in the .la file is really not a good idea in my
> opinion.  I think this should work recursivly, and find the other
> libraries it should link to from the .la files it references.

Huh?  If you use symbols from it, you should link against it --
otherwise an incompatible update of the library will leave you with
possibly subtle breakage at execution time.  And if you don't use
the library directly, then your link_all_deplibs=no should prevent
linkage against it (unless I am missing something).

If libtool decides to link against a library, I see no reason why that
deplibs should not show up in dependency_libs.

Maybe I am misunderstanding you again.

> So, I've tried what the effect is of having only things you link
> to in the dependency_libs of the .la file.  And it already seems
> to be working recursivly, so I have to wonder why they're all
> there.  Are there any plans on changing that behaviour soon?

Again, please show with an example of how it behaves before/after the
patch.

> I've all been testing this with 1.5, and have no idea how HEAD or
> something is doing this.
> 
> I've attached a patch that "works for me".  I'm not even sure
> this is the proper way to do what I want, it just seems to have
> the effect that I want.  I would welcome some comment on it.

What systems have you tested on?

To be honest, any change to the dependency algorithm needs, to be able
to go in, test exposure on at least, 
  GNU/Linux
  w32
  Darwin
  AIX with and without runtimelinking

and ideally some other systems as well, in order to cover the various
differences in link editor and runtime linker hardcoding behavior.

And yes, given time I am certainly very willing to help, and I can test
a lot, too.  After 2.0 is out.

Note we also know of a couple of open bugs in the current code that do
not have to do with link_all_deplibs=no.  They should probably be fixed
first.

> Do you think this can break something?

Yes.  Very certainly the patch below can and will break something.
I mean, it's even unconditionally for any architecture.  No Go.

> Is there a better way to solve those problems?

Dunno yet: need more information.

Cheers,
Ralf

> --- ltmain.in.old     2005-12-05 00:45:03.000000000 +0100
> +++ ltmain.in 2005-12-05 00:10:32.000000000 +0100
> @@ -2762,7 +2762,7 @@
>         # ... and its dependency_libs
>         tmp_libs=
>         for deplib in $dependency_libs; do
> -         newdependency_libs="$deplib $newdependency_libs"
> +#        newdependency_libs="$deplib $newdependency_libs"
>           if test "X$duplicate_deps" = "Xyes" ; then
>             case "$tmp_libs " in
>             *" $deplib "*) specialdeplibs="$specialdeplibs $deplib" ;;

[1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=297726
[2] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=291641
[3] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=320698