public inbox for gcc-prs@sourceware.org help / color / mirror / Atom feed
From: "Stephen M. Webb" <stephenw@cryptocard.com> To: pme@gcc.gnu.org Cc: gcc-prs@gcc.gnu.org, Subject: Re: libstdc++/9756: __verbose_terminate_handler enters infinite loop Date: Fri, 28 Feb 2003 21:06:00 -0000 [thread overview] Message-ID: <20030228210601.12505.qmail@sources.redhat.com> (raw) The following reply was made to PR libstdc++/9756; it has been noted by GNATS. From: "Stephen M. Webb" <stephenw@cryptocard.com> 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
next reply other threads:[~2003-02-28 21:06 UTC|newest] Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top 2003-02-28 21:06 Stephen M. Webb [this message] -- strict thread matches above, loose matches on Subject: below -- 2003-02-28 19:11 bkoz 2003-02-20 19:36 Stephen M. Webb 2003-02-20 17:06 Phil Edwards 2003-02-20 17:06 Stephen M. Webb 2003-02-20 16:26 Phil Edwards 2003-02-20 16:06 Stephen M. Webb 2003-02-19 22:06 Phil Edwards 2003-02-19 16:06 stephenw
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20030228210601.12505.qmail@sources.redhat.com \ --to=stephenw@cryptocard.com \ --cc=gcc-prs@gcc.gnu.org \ --cc=pme@gcc.gnu.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).