[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: C++ convenience libraries
From: |
Greg Hudson |
Subject: |
Re: C++ convenience libraries |
Date: |
Sun, 24 Aug 2003 02:32:37 -0400 |
> When libtool builds these convenience libraries, it adds the static
> libstdc++ library (by extracting the contents of libstdc++, then
> adding it to the convenience library)
I'm seeing the same thing on Solaris 9, with a gcc installed without
shared libraries. (I sent a note about it to address@hidden but
don't see it in the archives.) The following script demonstrates the
problem:
echo '#include <iostream>' > test.cc
echo 'void test() { std::cout << "1"; }' >> test.cc
libtool --mode=compile g++ -o test.lo -c test.cc
libtool --mode=link g++ -o libtest.la test.lo
echo '#include <iostream>' > test2.cc
echo 'void test(); void test2() { test(); std::cout << "2"; }' >> test2.cc
libtool --mode=compile g++ -o test2.lo -c test2.cc
libtool --mode=link g++ -rpath /tmp -o libtest2.la test2.lo libtest.la
One possible solution is to ignore postdeps when creating convenience
libraries.
I can demonstrate the problem in a less exotic environment simply by
creating a static library and using it. For instance, this script
generates a "multiple definition of 'stacy'" error on Linux.
cd /tmp
rm -rf inst *stacy* *sharon* *shawn*
mkdir inst
# Create Stacy, a static library.
echo "stacy() { }" > stacy.c
libtool --tag disable-shared --mode=compile gcc -o stacy.lo -c stacy.c
libtool --tag disable-shared --mode=link gcc -rpath /tmp/inst -o libstacy.la
stacy.lo
libtool --tag disable-shared --mode=install install -c libstacy.la /tmp/inst
# Create Sharon, a convenience shared library which uses Stacy.
echo "sharon() { stacy(); }" > sharon.c
libtool --mode=compile gcc -o sharon.lo -c sharon.c
libtool --mode=link gcc -L/tmp/inst -o libsharon.la sharon.lo -lstacy
# Attempt to create Shawn, an installable shared library which uses
# both Stacy and Sharon.
echo "shawn() { stacy(); sharon(); }" > shawn.c
libtool --mode=compile gcc -o shawn.lo -c shawn.c
libtool --mode=link gcc -L/tmp/inst -rpath /tmp/inst -o libshawn.la shawn.lo
libsharon.la -lstacy
It doesn't matter if you remove /tmp/inst/libstacy.la after the first
stanza; the result is the same. However, everything works (though a
bit oddly) if Sharon is created with an -rpath option. Perhaps it is
illegal to build Sharon as a convenience library with -lstacy; that
would be consistent with the "libtool should ignore postdeps when
creating convenience libraries" theory I supposed above.
I'm still looking for a good workaround for this problem. What I
wound up doing for gnu aspell was removing the -lstdc++ from postdeps
after libtool was created, and then adding -lstdc++ to the link
command for the generation of libaspell and libpspell. But that's not
very automated.