[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: removal of .la files from Debian and a possible solution to the libt

From: Kurt Roeckx
Subject: Re: removal of .la files from Debian and a possible solution to the libtool shared libs problem
Date: Mon, 31 Aug 2009 21:56:06 +0200
User-agent: Mutt/1.5.20 (2009-06-14)

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

Either you provided libb's depedencies when linking liba or
not, what is going to be in 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 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'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?


reply via email to

[Prev in Thread] Current Thread [Next in Thread]