[Top][All Lists]

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

Re: Several questions about libtool

From: Russ Allbery
Subject: Re: Several questions about libtool
Date: Sat, 07 Jan 2012 17:49:08 -0800
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.3 (gnu/linux)

Bob Friesenhahn <address@hidden> writes:
> On Sat, 7 Jan 2012, Russ Allbery wrote:

>> Do you mean for detecting other libraries?  Only for libraries without
>> pkg-config support.

> For detecting library features such as the availabilty of functions.

Yes, it deals with that fine.  Not that that's really on-topic, since I'm
not advocating everyone use pkg-config.

> Except that libtool is already embedded (in one vintage or another) in
> the source code of perhaps 5000 (???) different packages.  This makes
> the pace of change somewhat glacial.

So?  New versions are still being released, and people eventually upgrade.
I didn't say that we could resolve this problem overnight.  But I
guarantee it won't ever get fixed if, every time it comes up, the response
is negativity and defeatism about why it can't be fixed.

It's frustrating that GNU/Linux distributions have to drop *.la files
completely, dropping the other features that Libtool could be providing,
because of this ongoing issue.  Yes, it's not a trivial problem to solve
and it requires some thought about how to specify new linking semantics in
different situations, combined with detection of when one is in those
situations, but it's not impossible.

> Believe it or not, there are still people who download source packages
> and install software by building it from source code, or who develop new
> software from scratch, or by modifying existing source code.  Due to
> this, the pristine environment that the GNU/Linux distribution package
> maintainer is aware of is not necessarily representative of the user's
> system, or the user's intentions.  Given the principles of free
> software, we should not assume that software users will only get the
> software via carefully-prepared and managed binary packages provided by
> an OS distribution.

I don't see what this have to do with the library maintainer knowing
whether or not, for systems with ELF transitive dependency closure,
clients of their libraries should be linked with other libraries or can be
linked only with their library.  This is not a system-specific property,
nor is it something that is unknowable outside of a developer's

It does take some education of library maintainers on the issues, and
there have, of course, been bugs in pkg-config files.  But they get dealt
with.  It's really not that horribly hard of a problem for most libraries.
For nearly all libraries, in the pkg-config world, you can just put the
library itself in Libs and the libraries it links with in Libs.private.
There are some situations where you have to do something more complex, but
those are normally libraries that are more complex and have more expert

> Autotools needs to satisfy the requirements of completely different
> types of users.  This means that it still needs to work (best-effort) if
> pkg-config offers up some wrong (perhaps stale) information, or if the
> user has several independent (or complimentary) pkg-config installations
> on his system.  It also needs to work if pkg-config is not available at
> all.

Of course.  I think you've lost track of what I'm talking about.  I'm
pointing to pkg-config as a system that people have used to solve this
problem as something from which Libtool could pull ideas for how to fix
this problem in Libtool.  It doesn't make any sense to worry about
pkg-config files being stale or out of date in that context; the point is
that this would be incorporated into Libtool as a feature.

In doing so, I think there's some appeal in looking at the pkg-config file
format and seeing if the *.la file format could be merged with it, but
that was just an aside and is not something I feel strongly about.

> I feel that I may have gotten a bit off track here, but it should be
> clear that libtool needs to err towards the most reliable mechanisms by
> default (the software should build and work by default if at all
> possible) but also provide the features that distribution maintainers
> need.

Of course.  I've never advocated anything different.

Russ Allbery (address@hidden)             <>

reply via email to

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