Re: RFC: proposal for indirect deplibs

[Ralf Wildenhues]

* 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.)

> 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.

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.

Regards,
Ralf