Problematic linking between glibc and shared libgcc

[Laurent Guerby]

Richard Kenner wrote:
> Also, there are issues relating to conflicts (in the EH code)
> between libgcc and glibc. Unlike the GNAT RTS, very few C programs
> use any code from libgcc, so the advantage of having it shared is
> much less and the potential for problems of conflicts with glibc is
> the downside.

In the same vein, we had to link our GNAT/Ada software with KAI C++
code, and spent quite some time to find out why the whole thing core
dumped each time an exception was raised. It was because KAI C++
called a routine __throw which was unfortunately defined in libgcc.a
and just caused an abort. Hopefully we just had to remove _eh.o from
libgcc.a and everything worked fine again, I don't even know if this
kind of thing would have been possible with a shared system-installed
libgcc.

Are the planned libgcc entry points named with such general names as
__throw? Are these names part of the new standard C++ ABI?  If not,
why not call them __gcc3_throw to minimize the risk of conflict with
other software (and to document then that they are GCC specific)?

-- 
Laurent Guerby <guerby@acm.org>