Re: removal of .la files from Debian and a possible solution to the libtool shared libs problem

[Kurt Roeckx]

On Mon, Aug 31, 2009 at 08:55:21PM +0200, Ralf Wildenhues wrote:
> Hello Kurt,
> 
> * Kurt Roeckx wrote on Sun, Aug 30, 2009 at 10:31:39PM CEST:
> > 
> > I've mailed about this issue before.  What I think needs to
> > happen, and have proposed before, is:
> > - The .la file should only contain the libraries the current
> >   library links to
> 
> That will make it impossible to support static linking against libraries
> which do not themselves provide .la files.  We cannot do this upstream.

I don't see how it's different than what we have now.

If I understand what you're trying to say is:
- The lib we're making now, liba, links to libb
- libb itself does not have a .la file
- to link to libb staticly, you also need to link to other
  libraries.

Either you provided libb's depedencies when linking liba or
not, what is going to be in liba.la is going to be the same.

And if you really want static linking to work properly,
you need some way to find out what libraries libb requires,
be that with a libb.la or libb.pc file.

> > - Libtool should recursively read all the .la files in
> >   the .la file.
> 
> Again, this implies that all libraries of interest provide .la files.
> But Debian itself contributes to making that assumption be false.

And the main reason Debian currently doesn't want to ship .la
files is because they currently cause more problems than
they solve.

We want to link as much as possible shared.  But it would be nice
if we could make it easier for our users to link something staticly
if they want to do that.

> Besides, another issue that we currently have, and whose effect would be
> worsened by this change, is that deplib searches in staging directories
> need to take the staging prefix into account.

I'm not sure I really understand your point here.  But I think
it has to do with finding the right library at link time,
and that it makes things harder.  It's not because it's harder
that we shouldn't be doing it.

> > With that change only one .la file would need to be updated.
> 
> Well, for that you do not need that the .la file only contains the
> libraries the current library links to.  What you need is the following.
> 
> Assuming there is a deplibs and a private_deplibs (for static linking).
> Then, when your dependency walker is smart enough (and correct) to
> recurse .la files, then you can omit references to .la files which you
> only link against indirectly.  However, references to indirect
> non-libtool deplibs still need to be added to private_deplibs.

So you're saying that for the example above, you want to specify
libb's depedencies, and make them end up in liba.la's
private_deplibs, and that private_deplibs should only be used
for cases where the libraries we're linking to do not
provide the dependency info?


Kurt