libtool
[Top][All Lists]
Advanced

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

Re: RFC: proposal for indirect deplibs


From: Gary V. Vaughan
Subject: Re: RFC: proposal for indirect deplibs
Date: Sat, 27 Nov 2004 18:47:35 +0000
User-agent: Mozilla Thunderbird 0.9 (Macintosh/20041103)

Hey Ralf!

Ralf Wildenhues wrote:
* Albert Chin wrote on Fri, Nov 26, 2004 at 10:09:31PM CET:

On Wed, Nov 24, 2004 at 10:19:44AM +0100, Ralf Wildenhues wrote:

Before Libtool version 2.2, the handling of inter-library
dependencies has ignored the fact that some system linkers are smart
enough to figure out the library dependencies of dependent libraries
themselves, and always linked in all dependencies into the output.

*snip*

So, if we do what you want, libtool behaves different depending on the
platform.


As in: On systems without shared libraries, it links statically
instead of shared.  Difference between platforms: Update derived
objects after every change instead of after every interface change.

Or in: On systems without dlopen mechanism, libltdl emulates it
using dlpreopen.  Difference between platforms: similar as above.

My proposal: On systems with "smart linker": for every interface
change, only update the set of libraries and programs exposed to
this change.  (That is, if we can come up with a sane set of
semantics.)

I'm right behind you for this one, and think that it would be a huge
value add for libtool-2.2 -- as long as we heed the caveats pointed
out by Bob.

Is that really what we want?


I don't know.  Convince me to the contrary.

To me, the idea does not look out of line.  If libtool really were
to implement the same semantics on all platforms, it'd have to do
static linking only.  Well, you don't need libtool for that.  (Yes,
I've probably been the only person in years trying to actually use
libtool on a static-only platform).

What's more, there is precedence here: Debian's libtool makes use of
link_all_deplibs=no.  I would like something much more conservative
than this overall trust in library authors, but something better
than having libtool guess what ultimatively cannot be guessed.

s/precedence/precedent/ (prod me if you hate having your grammar
corrected, like wot I do, and I'll stop it)

Actually, I also believe that it's a good thing to support the
enhanced features that a GNU system (which GNU libtool is part of)
can offer, if (and only if) we can support them in a portable,
backward-compatible and smoothly-declining (does this word make
sense?) fashion.  E.g., I'd like versioned symbols as well, but
they seem to be impossible to realize while fulfilling the last
mentioned property.

"degrading gracefully" is the term I have always used.  Open Source
is almost always an evolutionary process, so we can only take it one
step at a time... best of all, if we step out of line, it is usually
easy to get back on track and try again with something else :-)

Cheers,
        Gary.
--
Gary V. Vaughan      ())_.  address@hidden,gnu.org}
Research Scientist   ( '/   http://tkd.kicks-ass.net
GNU Hacker           / )=   http://www.gnu.org/software/libtool
Technical Author   `(_~)_   http://sources.redhat.com/autobook

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

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