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

[Kurt Roeckx]

On Tue, Dec 06, 2005 at 08:25:15AM +0100, Ralf Wildenhues wrote:
> 
> Well.  Given above thoughts, I would think that your change makes sense
> in the link_all_deplibs=no setting, given that the package author knows
> about this.
> 
> Erm.  Except: what about static linking in that case?
> I think there is an implicit assumption in ltmain that if
>   P -> libA -> libB -> libC
> 
> then picking up libA's dependency_libs will give you all you need,
> ie., you do not need to walk recursively.  For static linking, you will
> need to do this now.  ltmain does not implement this walk at the moment.

Then that is something that needs to happen.  I did some basic
tests to see if this worked, and I thought it did, but I didn't
really take a close look to it.

> > Now I try to link to libC, and if I only look at libC's
> > .la file, it says it should link to libA and libB, but not
> > to libD.  This mean that in case of static linking it will
> > break, unless it also goes and looks at libA's .la file.
> 
>         P --> libC --> libA --> libB
>                             `-> liBD
> 
> Correct.  It's an instance of the 'ltmain needs to do the walk'
> issue.

Do you know in what cases it does the walk, and in what cases it
doesn't do it?

> > What I would like to see is that libC's dependency_libs
> > only have libA in it, and should never contain libB or
> > libD, which is just an "implementation detail of libA".
> 
> True, in the link_all_deplibs=no case.

I believe it's also true in the link_all_deplibs=yes case, but
only if it does the walk of the dependencies.

> > So the 2 problems I've mentioned (convience libs and
> > adding/removing dependencies) both seem to have a simular
> > solution, reducing the dependency_libs to what was on the
> > command line when making that library.
> 
> Well, yes, but solving this without breakage simply requires that
> ltmain walk the dependency chain.

So I guess we should concentrate on getting that right.

> > > What systems have you tested on?
> 
> > I only have access to GNU/Linux, so I can't test this
> > myself.
> 
> If you can help out providing tests, I can easily test them on a number
> of platforms

But you want test for HEAD right?  Maybe I should try and get
this working in HEAD instead.

I should probably also get a more recent version in experimental,
and maybe I can play with some of those changes there without
breaking too much.

> Well.  If people link convenience archives directly in programs
> (which they shouldn't, but they do), then this patch will break it.
> 
> You also need to take into account that quite a few users
> - either don't install the .la files (which we may rightfully,
>   declare as "it's their problem then", but in reality that will
>   be another maintenance nightmare)

If the .la file isn't installed, it doesn't matter what is in it.

> - or, and that is more important, where a lot of the installed
>   libraries simply were never created with libtool, e.g., because
>   they stem from a proprietary OS.  There, having indirect dependency
>   information is very valuable.

So in this case you don't have an .la file either.

I'm guess I'm missing the point here.

If you're talking about an other library linked to any of those
2, then I agree that it should contain those in it.  And my
suggestion wouldn't change that.

As summary, I think the following needs to happen:
- Check that depedencies get walked recursivly, and do it in
  all cases.
- Write tests for all the cases mentioned so far.  Some might
  break with the current versions too.
- If that's done, look at reducing the number of dependencies
  in .la files that get mentioned.


Kurt