[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

 > 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

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

But then, I wouldn't have a self-contained libfull, would I?


reply via email to

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