This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]