Gcc 3.4.0 is not compatible with glibc

["H. J. Lu" <hjl at lucon dot org>]

FYI, gcc 3.4.0 and above is not compatible with glibc:

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14660
http://sources.redhat.com/bugzilla/show_bug.cgi?id=81

The problem is libgcc assumes EH used in libgcc comes from the same
place. Unfortunately, it is not true with the current scheme. We
may have the situation where part of EH comes from executable and
part of EH comes from libgcc_s.so. They won't work together if EH
depends on some private data are the same betweeen executable and
libgcc_s.so. Another problem is the one in executable may not be
compatible with the one in the newer libgcc_s.so. The end result is
programs compiled with gcc 3.4.0 or above, which link part of EH into
executable, may not work correctly today at all or may stop working
in the future. That is what I have been worried about even since
libgcc_s.so was first introduced.

I am not sure how this problem should be solved. To me, we can
make sure that EH will always come from one place and one place only.
I think having both libgcc_eh.a and libgcc_s.so will lead to trouble.
The current linker has a new option, --as-needed, which means we can
always pass "--as-needed -lgcc_s --no-as-needed" to the linker such
that libgcc_s.so will only be added to DT_NEEDED when some symbols in
it is referenced by the executable. We may have to modify libgcc_s.so
to make sure that only those which have to come from the same place
are exported.  Otherwise, libgcc_s.so will be added to DT_NEEDED when
__umoddi3 is referenced. Of course, we have to provide the backward
compatibility when a symbol is no longer exported.


H.J.