Subject: Re: libtool, C++ and shared objects
To: Hubert Feyrer <hubert.feyrer@informatik.fh-regensburg.de>
From: Marc Espie <espie@schutzenberger.liafa.jussieu.fr>
List: tech-pkg
Date: 08/20/2001 16:54:20
libtool assumes that libraries will be complete, including the compiler
cruft.

In general, libtool assumes it knows an awful number of things about
the system that it shouldn't.

I've run into these problems in OpenBSD and solved them a while before
2.9...

Shutting libtool up is as simple as deactivating the deplibs_check_method,
e.g., use pass_all, and pray you will have the libraries you need.

Note that the c++ -shared line is erroneous, as usual.
Using `c++ -shared' without some kind of pic flag is likely to get you
in trouble on at least some architectures.

In order to build complete libraries, you need a pic libgcc. This can
be achieved by tweaking TARGET_LIBGCC_FLAGS in the target configure
framgents. However, this is not always enough. In some cases, you need
separate libgcc versions for -fpic, -fPIC, and plain non-pic code (e.g.,
gdb is distinctly unhappy on i386-a.out with a -fpic libgcc...)

There's a MULTI_LIB support mechanism in gcc that will solve that handily.

However, in order to find the correct libraries, gcc invoked as a linker
MUST have the correct combination of flags, which leads us back to the
earlier bogus omission of -fpic in `cc -shared'.

When gcc 3.0 becomes usable, you'll note that all libraries in it have been
multi-libbed, so if you provide the correct configuration (and fix that
dreadful libtool for your platform), you'll have a correct collection
of libiberty/libgcc/libstdc++/libsup++/libobjc/libgcj/libg77, with 
normal, pic, .so flavoring as wanted.