16.4.3 Libtool C++ support
At the moment, Libtool is the weak link in the chain when it comes to
working with C++. It is very easy to naively build a shared library
from C++ source using
$ libtool -mode=link g++ -o libfoo.la -rpath /usr/local/lib foo.c++
This works admirably for trivial examples, but with real code, there are
several things that can go wrong:
On many architectures, for a variety of reasons,
to perform object linking using
ld. Unfortunately, the C++
compiler often links in standard libraries at this stage, and using
ld causes them to be dropped.
This can be worked around (at the expense of portability) by explicitly
adding these missing libraries to the link line in your `Makefile'.
You could even write an Autoconf macro to probe the host machine to
discover likely candidates.
The C++ compiler likes to instantiate static constructors in the library
objects, which C++ programmers often rely on. Linking with
will cause this to fail.
The only reliable way to work around this currently is to not write C++
that relies on static constructors in libraries. You might be lucky
enough to be able to link with
LD=$CXX in your environment with
some projects, but it would be prone to stop working as your project
Libtool's inter-library dependency analysis can fail when it can't find
the special runtime library dependencies added to a shared library by
the C++ compiler at link time.
The best way around this problem is to explicitly add these dependencies
libtool's link line:
$ libtool -mode=link g++ -o libfoo.la -rpath /usr/local/lib foo.cxx \
Now that C++ compilers on Unix are beginning to see widespread
acceptance and are converging on the ISO standard, it is becoming
unacceptable for Libtool to impose such limits. There is work afoot to
provide generalized multi-language and multi-compiler support into
Libtool----currently slated to arrive in Libtool 1.5. Much of the work
for supporting C++ is already finished at the time of writing, pending
beta testing and packaging(36).