Re: exclusive static or shared

[Ralf Wildenhues]

Hi Christopher,

* Christopher Hulbert wrote on Wed, Feb 15, 2006 at 04:10:20PM CET:
> 
> Lets say I build library liba as both static and shared (thus I have
> liba.a and liba.so or liba.lib and liba.dll).  I later want to build
> libb.so or libb.dll against the installed liba.  From my observations
> it always takes the shared liba.  Is this true, or is there a flag to
> tell it to use static libraries where available (similar to -i-static
> for intel compiler).
> 
> I was thinking something like -libtool-static or
> -libtool-static=-la,-lxyz where the comma-separated list is a list of
> libraries this rule applies to.  Any thoughts on the matter?

Yes, there are some thoughts:

First, don't let shared libraries have static libraries as dependencies.
It's a pain, there are many systems where this will not work as desired,
and making sure you never end up with duplicate symbols and/or arising
subtle bugs is not easy.  Text relocations cost shareability and lots
of memory on some systems, and if they cause a sufficient speedup, it
usually means your interface design is broken.  Surely I acknowledge
that on _some_ systems things may be differently, but Libtool is about
portable library creation.  And after all, it is possible to achieve
this now by the workaround of creating several instances of a library
(don't bother us with bug reports then, though; I won't read them).
On systems without pass_all, libtool will not actually _include_ the
static library into the shared one, though, but record the dependency
in the .la file so that it can be fulfilled when a program is created.

Second, there was recently a longish thread about per-deplib static/
shared flags for creating programs, including patches.  Likely, soon
after 2.0 is released some progress on that issue can be expected.  ;-)

Third, there is a pending patch implementing `-static-libtool-libs',
to be applied before 2.0 hopefully.

Cheers,
Ralf