Re: Shared libstdc++ on AIX

[David Edelsohn <dje at watson dot ibm dot com>]

	By the way, the __throw_bad_cast() error is indicative of the
shard symbol problem and is caused by exactly the duplicate symbols for
which one receives warnings if linked statically.

	The problem is that AIX does not have weak symbols and links
symbols tightly within a shared library.  On SVR4, the weak symbols would
remain unbound and would be merged between all shared objects and the main
application in the process.  On AIX, libstdc++ shared library has one copy
of the symbol it uses and the application has another.

	Basically the shared library consituents have COMMON symbols.
When the shared library is created, there is no STRONG definition, so the
COMMON symbols create the definition in the BSS section.  The application
also contains the symbols and is linked to its definition.  The two
definitions are not shared when the library is referenced as a shared
object at runtime.  AIX normally does merge the TOCs for global symbols
the way that SVR4 creates a unified GOT for the process.

	The end result of all of this is that libstdc++ uses its internal
definition of std::num_get<>::id, etc. which is ZERO (0) because it is
using the COMMON symbol bound into BSS.

	When one links the application statically, the shared library
symbols *ARE* merged at link-edit time.  One gets the duplicate symbol
warnings, but the application and library have a single, correct, shared
symbol as expected (the DATA section definition wins).

	AIX has a -brtl option to perform TOC rewriting at runtime similar
to SVR4 GOT behavior.  However, -brtl was not expected to be used with
static linking.  One can create libstdc++.so as a SVR4-style AIX "rtl"
library, but then static linking fails for EVERYTHING.

	Basically, we're in a no-win situation at the moment until various
problems are fixed in both G++ and AIX.  The pieces of C++ that do not hit
the shared symbol problem do work.

	Note that the way this normally would be handled in AIX is to
place the COMMON symbols into a normal object file archived with the
shared object (because AIX shared libraries are normal archives of object
files which can contain multiple object files).  Then the symbol sharing
of COMMON symbols is resolved at link-edit time using the normal rules and
everything works.  G++ cannot easily generate this type of segregation of
symbols into separate object files at the moment.

	I think that the problems are well understood, but there is no
easy or short-term solution that I have been able to find.

David