GCC 3.2 runs with glibc-2.2, crashes with glibc-2.3?

[Jim Wilson]

yuvalk@mainsoft.com wrote:
> What could be the source of the problem? This does not happen if I use Red Hat's
> flavour of GCC 3.2 (that comes with RHL 8.0 for example).

This sounds like an obscure gcc/glibc interaction problem.  You may not 
get much help from gcc volunteers, as it doesn't seem worth our time to 
try to track this down.

I am not even sure if what you are doing is valid.  I don't know if you 
can expect a shared library linked against glibc-2.2 to work with 
glibc-2.3.  It sounds a bit risky.  It might be helpful to ask the glibc 
folks about this.

The RHL 8 gcc-3.2 has a number of patches applied to it.  Maybe one of 
them fixes this problem?  You could always try building the RHL 8 
gcc-3.2 sources on RHL 7.

The _deregister_frame_info call would be from gcc code for handling 
dwarf2 CFI-based unwind info.  The unwind info is registered by code in 
the init section, and unregistered by code in the fini section. 
Normally this code would come from libgcc, but if the libgcc routines 
aren't there then glibc routines are used instead.  You are getting the 
glibc routine here.

You might try experimenting with libgcc.  Maybe linking libgcc 
statically  will help?  Try --static-libgcc.  However, this may break 
C++ programs using EH.  Or maybe libgcc didn't get linked in?  Or maybe 
the shared libgcc on the RHL8 system is not compatible with the shared 
libgcc on the RHL7 system?
-- 
Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com