From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12519 invoked by alias); 28 Feb 2003 21:06:01 -0000 Mailing-List: contact gcc-prs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-prs-owner@gcc.gnu.org Received: (qmail 12506 invoked by uid 71); 28 Feb 2003 21:06:01 -0000 Date: Fri, 28 Feb 2003 21:06:00 -0000 Message-ID: <20030228210601.12505.qmail@sources.redhat.com> To: pme@gcc.gnu.org Cc: gcc-prs@gcc.gnu.org, From: "Stephen M. Webb" Subject: Re: libstdc++/9756: __verbose_terminate_handler enters infinite loop Reply-To: "Stephen M. Webb" X-SW-Source: 2003-02/txt/msg01501.txt.bz2 List-Id: The following reply was made to PR libstdc++/9756; it has been noted by GNATS. From: "Stephen M. Webb" To: bkoz@gcc.gnu.org, gcc-bugs@gcc.gnu.org, gcc-prs@gcc.gnu.org, nobody@gcc.gnu.org, pme@gcc.gnu.org, gcc-gnats@gcc.gnu.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@gcc.gnu.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