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

[Ralf Wildenhues]

Hi Kurt,

* Kurt Roeckx wrote on Tue, Dec 06, 2005 at 06:51:38PM CET:
> 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.

Agreed.

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

Just keep a typescript of your sessions.  Mangling that into a test
becomes easy over time.

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

AFAIK it always assumes the first level deps give you the transitive
closure.  I may be wrong, because I haven't understood how the several
passes work.

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

Not if you have to deal with installations lacking .la files.

Really: The only sane way we can get this done without breaking
backward compatibility and retain user-expected behavior is if we
- implement the walking and all that stuff
- make library authors be aware
  (ie. they need to state, maybe with a command line switch: I
   have listed all my direct dependencies)
- make the user (the one that builds the stuff) be willing to
  have non-transitive listings.

And also get all of this in a way that Debian can still upgrade
gradually from their current set to the new.  I believe it is possible.
For example, if we allow arguments from some environment variable,
or some other debian-build global setting.  Would you agree with this?

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

Correct.  Ensuring correctness is best done by having a good set of
regression tests.

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

Most definitively.  We've wasted much too much time on branch-1-5.
I'll want to shove bugfixes in it for a while, because I believe
that to be user-friendly, but no new features.  I really hope we
get out a 2.alpha very very soon (and that it turns up few issues,
so that 2.0 can be released shortly afterwards).

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

Debian packages are certainly a very good testing ground, but they do
expose only one type of linker behavior.

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

But, on some systems, the library we just compile *will need* to link
against all other libraries.  That means, for package authors, they
may need to take into account that they can't rely on installed .la
files taking this burden off of them.  Even with the non-transitive
dependency_libs, all libs may need to be listed.

Besides, you're missing the point here: just because the installed
system does not use .la files, doesn't mean a user that happens to
install below $HOME does not want to use it.

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

Maybe I was unclear there: this doesn't impact the ltmain code, merely
library author education.

But I thought of another problem: libltdl needs to be able to walk, too.
Take this:
  P ..> M  -> libA -> libB

with all of them uninstalled.  libB is not found on some other systems
without libltdl explicitly walking.

And back when the deplibs stuff was discussed (about a year ago) before,
there was another item that came up: Do we want to support the notion of
exposure?  I.e., a header accompanying my library libfoo, foo.h, has
  static inline foo () { return bar(); }
where bar is from libbar.  Even if a user of libfoo believes not to use
libbar directly (after all, only public interfaces of foo are used), it
will be necessary to link against it.

By the way, you are aware of previous discussions, right?
http://lists.gnu.org/archive/html/libtool/2004-11/msg00455.html
http://lists.gnu.org/archive/html/libtool/2004-12/msg00029.html

> 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.
    if the user wants that.

- Express this in the resulting .la file.

I'm still undecided about whether the .la file should keep a full list
of dependencies in addition to the reduced list.  I see your argument
about changed library sets far down the road, but it would likely make
the transition, and providing the former behavior upon request, easier.

Cheers,
Ralf