Re: Installing convenience libraries

[Ralf Wildenhues]

Hello Akim,

* Akim Demaille wrote on Fri, Sep 29, 2006 at 10:41:36AM CEST:
> 
> I'm trying to build a convenience library, install it, build another
> convenience library on top of it (and again install it), and finally
> link an executable using the latter library.

Convenience archives are not intended to be installed.

Why?  Because that breaks dependency analysis, and it's not clean style.
The former could be fixed in Libtool, but the latter leads to problems
such as these scenarios:

Someone finds a security issue in libconv.a.  You update it and install
a fixed version.  Since it's not a shared library, you have to relink
all programs that depend on it (this step is identical what you have to
do with ordinary static libraries; there is no way around this).  But
since it's also not a regular static library, there may be any number
of shared libraries that contain the buggy code.  Their .la files won't
reveal it.  This situation is ugly.

But the ugliness happens even earlier: say, you create shared libraries
liba1, liba2, liba3, from a convenience archive libconv.  Assume libaX
are from different packages, different versions.  (This is a practical
assumption, since, if all libraries were from the same package or tree
of packages, you wouldn't have the need to install libconv in the first
place.)  Now, if you link a program against libaX, it depends upon the
order at link time which libconv code will be used, the one that's in
liba1, or in liba2, or in liba3.  So implicitly you have now exposed
the API of libconv to the world, because the code from liba2 may at run
time use the symbols from libconv that are in liba1.

Thus, it's best not to install convenience archives, and to only link
them into one shared library at most, and not into any programs, just
as the Libtool manual states.

Maybe you rather want to use an installable static library?
  libtool ---mode=link $CC ... -static -rpath /install/path \
          -o libfoo.la foo.lo ...

Cheers,
Ralf