Re: libstdc++/9756: __verbose_terminate_handler enters infinite loop

["Stephen M. Webb" <stephenw at cryptocard dot com>]

The following reply was made to PR libstdc++/9756; it has been noted by GNATS.

From: "Stephen M. Webb" <stephenw at cryptocard dot com>
To: bkoz at gcc dot gnu dot org,
 gcc-bugs at gcc dot gnu dot org,
 gcc-prs at gcc dot gnu dot org,
 nobody at gcc dot gnu dot org,
 pme at gcc dot gnu dot org,
 gcc-gnats at gcc dot gnu dot org
Cc:  
Subject: Re: libstdc++/9756: __verbose_terminate_handler enters infinite loop
Date: Fri, 28 Feb 2003 16:01:34 -0500

 On February 28, 2003 02:11 pm, bkoz at gcc dot gnu dot org wrote:
 >
 >     Hmmm. I believe libgcc_so does have versioning support. Can somebody
 > confirm this is really the problem?
 
 I just checked, and libgcc_so does have symbol versioning (where supported).
 
 >     Stephen can you give more detail about this bit:
 >      I seems that the library libgcc_s.so.1 has been changed between 3.2
 > and the latest CVS source, but does not have versioning support.
 
 It turned out the problem was that the dynamic linker/loader was resolving 
 libgcc_s.so.1 for my executable built by gcc 3.4 to the libgcc_s.so.1 built 
 by gcc 3.2.
 
 The 3.2 _Unwind_RaiseException() just fell through in __cxa_rethrow(), which 
 resulted in std::terminate() being called (which in turn called 
 __cxa_retrow(), ad infinitum).
 
 When I forced the right libgcc_s.so.1 to be picked up (by setting 
 LD_LIBRARY_PATH correctly *blush*), the 3.4 _Unwind_RaiseException did the 
 Right Thing and actually rethrew the exception.
 
 This leads me to believe that code produced by the 3.4 compiler is not 
 backwards compatible with the runtime libraries built by the 3.2 compiler.  
 Usually when this happens with a runtime library, the version number of the 
 library itself gets bumped (libstdc++ does so, as does libc), allowing 
 incompatible versions of the library to exist alongside each other.  This is 
 evidently not the case for libgcc_s if the two versions are in fact 
 incompatible.
 
 If someone can prove that there are incompatibilities between the two versions 
 of the library, the name should be changed to match, otherwise there are 
 potential problems with software distribution (not to mention multiple 
 versions of the toolchain existing side-by-side).
 
 -- 
 Stephen M. Webb