repost: libg++ won't build on alphaev56-dec-osf4.0d

[Zack Weinberg]

On 20 Dec 1998 03:58:17 -0200, Alexandre Oliva wrote:
>
>The point is that libstdc++ is a library we build together with egcs.
>Users of DU4 won't be able to create shared libraries with g++ (or
>with gcc, explicitly linking libstdc++ and libgcc in): they'll get a
>symbol redefinition error :-(
>
>IMO, creating libstdc++ in a way that it doesn't include symbols from
>libgcc is not a major problem, because programs that link with
>libstdc++ are supposed to link with libgcc too.
>
>The right fix for this problem would be to arrange that the symbols
>imported from libgcc are not exported from libstdc++; maybe doing
>something similar to what H.J.Lu's been doing for Linux would fix the
>problem on DU too.

H.J.'s patches will not help here.  They attempt to fix a related
problem with symbols from libgcc appearing in shared libraries, but do
not address the case of the linker objecting to the same symbol in two
libraries.

H.J. has two patches for the Linux problem.  One modifies crtstuff
such that pure C programs or libraries will not link in the eh
functions from libgcc.a.  This is a good patch and should be applied.
It should not be considered to fix the problem of random functions
from libgcc appearing in shared libraries.

The other patch he has forces some (not all!) libgcc symbols local in
shared libraries.  This must not be applied, because it will create
yet another set of binary incompatibilities and not fix the actual
problem.

The actual problem - and it's the same problem for DU and Linux - is
as follows:

- all shared libraries and executables must be linked with libgcc.a
- NO symbol in libgcc.a can be re-exported by ANY shared library

I don't like to shout, but this is a critical bug which no one seems
to understand.  The compiler generates references to symbols in libgcc
silently and unpredictably.  As it stands, a shared library will
re-export the subset of libgcc symbols it uses.  This subset will be
different between different releases of the compiler.  When an
executable is linked against shared libraries that provide libgcc
functions, the DU linker barfs.  GNU ld doesn't care, but when you
move that executable to another system where the shared libraries have
been compiled by a different version of the compiler, ld.so will barf.

The problem affects all languages and all platforms that support
shared libraries.  It has only showed up in C++ related code recently
since the internal ABI is in flux.  C code tends to only use things
like __muldi3 which change rarely if ever, but all versions of egcs
to date have a crtbegin.o that pulls in the EH functions whether you
need them or not, and that makes C code depend on the unstable C++
interface.  (This is what HJ's first patch fixes.)

Making libgcc a shared library on all platforms where this is possible
will fix the bug.  This is the simplest fix and I think we already
have support for it.  It may not be the right fix.  Another
possibility is to remove all the C++ support functions from libgcc.a
and put them somewhere else, like libstdc++ or a new
libg++internal.so.  The library where they wind up has to be shared.
I don't think this would fix the entire bug.  Some of the
"C++ support" functions are actually intended to be general - e.g. all
languages that use exceptions need __register_frame_info.  

zw