Installing convenience libraries
[Please keep me in CC.]
Hi,
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.
I thought I could do that using Libtool static libraries with
extension .la, but it seems I can't do that. It works well with
.o/.a, but with .lo/.la, it fails without an explicit explanation:
| + libtool --tag=CC --mode=compile gcc -static foo.c -c -o foo.lo
| mkdir .libs
| gcc foo.c -c -fPIC -DPIC -o .libs/foo.o
| gcc foo.c -c -o foo.o >/dev/null 2>&1
| + libtool --tag=CC --mode=link gcc -static foo.lo -o libfoo.la
| ar cru .libs/libfoo.a foo.o
| ranlib .libs/libfoo.a
| creating libfoo.la
| (cd .libs && rm -f libfoo.la && ln -s ../libfoo.la libfoo.la)
| + libtool --tag=CC --mode=install install -c libfoo.la
/tmp/test-libtool.sh.tmp/lib/libfoo.la
| install -c .libs/libfoo.lai /tmp/test-libtool.sh.tmp/lib/libfoo.la
| install: cannot stat `.libs/libfoo.lai': No such file or directory
Am I trying to do something silly? This is
ltmain.sh (GNU libtool) 1.5.22 Debian 1.5.22-4 (1.1220.2.365 2005/12/18
22:14:06)
If you want to try, use the attached script. Without argument it uses
.o/.a, with -l it uses .lo/.la. I'd like to stick to Libtool
libraries because eventually we will probably move to using dynamic
libraries (i.e., the first library libfoo would remain a convenience
library, which should be later integrated into libbar so that the
latter is really self-contained. Not clear this is doable...).
Any help is appreciated!
#! /bin/sh
set -ex
case $1 in
-l) ext=l;;
'') ext=;;
*) exit 1
esac
libtool='libtool --tag=CC'
tmp=/tmp/$(basename $0).tmp
rm -rf $tmp
mkdir $tmp
cd $tmp
mkdir lib
make_object ()
{
base=$1
cat >$base.c <___
http://lists.gnu.org/mailman/listinfo/libtool
Re: Installing convenience libraries
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 ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Installing convenience libraries
>>> "Ralf" == Ralf Wildenhues <[EMAIL PROTECTED]> 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! ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Installing convenience libraries
Hello Akim, * Akim Demaille wrote on Fri, Sep 29, 2006 at 12:05:39PM CEST: > >>> "Ralf" == Ralf Wildenhues <[EMAIL PROTECTED]> writes: > > > > 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): Actually, I think it really means "convenience archives". And I think it stems from a time when convenience archives were not named *.la. And this still works, so you can use it as a workaround as long as things don't work with libconv.la. (The only system it won't work on then is w32 with MSVC with the LIB archiver instead of ar.) Hmm. By default the libtool --mode=link $CC -o liba.a a.lo will choose the non-PIC object though; so you will have to put -prefer-pic into compile mode flags, or --tag=disable-static in compile mode flags before --mode=compile. (The latter avoids double compilation). I'm not sure whether I want to classify any of these as bug (except the documentation one). I'm very reluctant to make installability for convenience archives too easy for users, for fear of the scenarios stated. > > 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 Hehe. I knew it, I should've written this instead: | (This is a practical assumption in free software environments [...]) ;-) > 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? Sure they may be useful in this setting. But I still don't understand why you just don't simply make libcore be an ordinary shared library? Is that because of relocatability issues? > > (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. I agree that in this case it may be a practical one. Another one may be to create a relocatable object that contains all the other ones, i.e., do partial linking ld -r -o liballofit.o obj1.o obj2.o Libtool advertises to do this portably, but that functionality still has (old) bugs. Also since it's not so often used, GNU binutils ld has bugs with it on some systems (MinGW at least, IIRC). > > 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? No, you wouldn't. Cheers, Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Installing convenience libraries
>>> "Ralf" == Ralf Wildenhues <[EMAIL PROTECTED]> writes: Thanks Ralf, > (The only system it won't work on then is w32 with MSVC with the > LIB archiver instead of ar.) Bummer. But I'm not surprised :) > Hmm. By default the > libtool --mode=link $CC -o liba.a a.lo > will choose the non-PIC object though; so you will have to put > -prefer-pic into compile mode flags, or --tag=disable-static in compile > mode flags before --mode=compile. (The latter avoids double > compilation). Thanks for the details! > I'm very reluctant to make installability for convenience archives > too easy for users, for fear of the scenarios stated. I can afford a --yeah-I-want-to-install-a-convenience-library :) >> 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? > Sure they may be useful in this setting. But I still don't understand > why you just don't simply make libcore be an ordinary shared library? > Is that because of relocatability issues? Eventually we sure will use shared libraries, but as of today, it seems simpler to first deal with only static libraries. Besides, my real problem is making an archive self-contained. Unless you are saying that if I had a "shared" libcore (the convenience one) I could link it directly inside libfull.so? > I agree that in this case it may be a practical one. Another one > may be to create a relocatable object that contains all the other > ones, i.e., do partial linking > > ld -r -o liballofit.o obj1.o obj2.o That's nice! I wasn't aware of this feature. I must say that I don't know enough on object files to tell what the difference is with a genuine library. The toc I guess. I'll do my homework and look for information on the Internet :) > Libtool advertises to do this portably, but that functionality still > has (old) bugs. Also since it's not so often used, GNU binutils ld > has bugs with it on some systems (MinGW at least, IIRC). Guess what: that's one of the targets :( ___ http://lists.gnu.org/mailman/listinfo/libtool
