[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Installing convenience libraries
From: |
Akim Demaille |
Subject: |
Re: Installing convenience libraries |
Date: |
Fri, 29 Sep 2006 12:05:39 +0200 |
User-agent: |
Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux) |
>>> "Ralf" == Ralf Wildenhues <address@hidden> writes:
> 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.
This is a quote from the documentation:
You can even install a convenience library using GNU Libtool,
though you probably don't want to and hence GNU Automake doesn't
allow you to do so.
I guess it should read "static" instead of "convenience", in
particular since the example seems to refer to a plain library (it
uses .a):
burger$ libtool install ./install-sh -c libhello.a /local/lib/libhello.a
./install-sh -c libhello.a /local/lib/libhello.a
ranlib /local/lib/libhello.a
burger$
> 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:
My scenario is really different from yours (which does make a lot of
sense in a given environment). Mine does not have the problem you
raise. Say you have a company that ships libfull which is composed of
a libcore and extra stuff. Only few people have access to the sources
of libcore, but libcore is installed on developer stations so that
they can work on the extra-sources to put into libfull (which includes
libcore). libfull is provided to the clients, and it should be
self-contained.
Isn't what libtool convenience libraries are tailored to do?
> 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.)
Yes, I do. Or maybe not: that seems like the best means to provide
the libcore to libfull developers.
> Maybe you rather want to use an installable static library?
> libtool ---mode=link $CC ... -static -rpath /install/path \
> -o libfoo.la foo.lo ...
But then, I wouldn't have a self-contained libfull, would I?
Thanks!