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

[Kyle Sallee]

libxcb version 1.0 installed:

/usr/lib/libxcb-xlib.la
/usr/lib/libxcb-xlib.so
/usr/lib/libxcb-xlib.so.0
/usr/lib/libxcb-xlib.so.0.0.0

However, libxcb version 1.4 did not install the above mentioned files.

libX11 version 1.1.3 linked using /usr/lib/libxcb-xlib.la.
All software linked with libX11
by using the information provided in libX11.la
also links with libxcb-xlib
Consequently, that software, if it is a library,
also installs libtool archive files
that contained a reference to /usr/lib/libxcb-xlib.la

However, installed software that does not directly use libxcb-xlib
does not need to be explicitly linked with libxcb-xlib.
If such software was linked with libX11
and libX11 was linked with libxcb-xlib
then the libxcb-xlib library would also be loaded when libX11 is loaded.
The software that links with libX11
does not have a need to know about libxcb-xlib
as long as libX11 was correctly linked.
The important question is, "Why does it matter?"

In order to correct this problem following the update of
libxcb from version 1.0 to version 1.4 the only software
that should be required to recompile is libX11.
However, due to much installed software be linked with
the now missing libxcb-xlib library
and also the many .la files that reference libxcb-xlib.la
all those software projects must also be recompiled, relinked, and reinstalled.
That will amount to over 100 software projects on some boxes.

This is a real example of something that is really happening
and not a hypothetical libA libB conjecture.
I hope the elaboration would demystify one of
the more troublesome aspects about libtool.

While I prefer to not do all that compiling,
merely sediting libtool archive files will not solve the problem.
Fortunately, I use a distribution that automatically detects
and corrects problems due to library updates.
Consequently, I am care free.

However, if I used a pre-compiled binary based distro
then I would instead be downloading
hundreds of replacement packages
instead of merely recompiling sources that my boxes previously acquired.
Something like that might give maintainers of a pre-compiled
binary based distro cause to carefully reconsider both the use
and content of libtool archive files,
because such changes could avoid a +100 megabyte download update.

I agree that this topic of conversation
is worthy of the libtool mail list
and should not be confined to a distribution's email list.
>From one point of view this type of problem
is caused due to something libtool is doing
rather than something that distribution maintainers
and software authors are intentionally doing.
Furthermore, I do not know the situation with Debian maintainers.

I do not care if anything is done about this type of problem.
However, if I deployed a pre-compiled binary based distro
then I would probably have an opinion.
Yet it would seem that if this is a problem worthy of being fixed
then it should be fixed by libtool authors
instead of the maintainers of pre-compiled binary distribution.

I apologize if the information that I provided
is not congruent with the subject.
As I wrote above I do not what Debian maintainers are doing nor why.
However, if I were to make a wild guess
then I would speculate that an update
such as the one I described above
might be sufficient to provoke the ire of Debian maintainers.


On Tue, Sep 1, 2009 at 9:33 AM, Kurt Roeckx<address@hidden> wrote:
> On Mon, Aug 31, 2009 at 04:38:04PM -0400, Mike Frysinger wrote:
>> On Monday 31 August 2009 15:56:06 Kurt Roeckx wrote:
>> > On Mon, Aug 31, 2009 at 08:55:21PM +0200, Ralf Wildenhues wrote:
>> > > * 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.
>>
>> and Ralf is pointing out that by trimming dependency_libs, you're breaking
>> libb.la when linking libb statically via libtool.  if there is no libb.la,
>> then the issue is irrelevant because we arent talking about libtool scripts. 
>> -
>> mike
>
> You mean that if liba.la was created when there was a libb.la that
> did contain the needed info?  In that case trying to use liba.la
> now already fails, because it's looking for libb.la.
>
> In case liba.la never knew about a libb.la, or libb.a never existed,
> I can't see any difference.
>
>
> Kurt