From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10936 invoked by alias); 20 May 2003 18:29:43 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 10612 invoked from network); 20 May 2003 18:29:38 -0000 Received: from unknown (HELO hub.ott.qnx.com) (209.226.137.76) by sources.redhat.com with SMTP; 20 May 2003 18:29:38 -0000 Received: from webmail.ott.qnx.com (webmail.ott.qnx.com [192.168.2.3]) by hub.ott.qnx.com (8.9.3p2/8.9.3) with ESMTP id OAA24667; Tue, 20 May 2003 14:25:36 -0400 Received: (from apache@localhost) by webmail.ott.qnx.com (8.11.2/8.11.2) id h4KHLYi08937; Tue, 20 May 2003 13:21:34 -0400 Message-Id: <200305201721.h4KHLYi08937@webmail.ott.qnx.com> To: "Joe Buck" , Subject: Re: libsupc++, _cxa references, and Dinkum libcpp Date: Tue, 20 May 2003 18:38:00 -0000 From: In-Reply-To: <20030520094658.A12888@synopsys.com> Cc: X-SW-Source: 2003-05/txt/msg01888.txt.bz2 Thanks, Joe. I appreciate your feedback. I was under the impression that gcc and libstdc++ were seperate products, and that the __cxa symbols being emitted by cc1plus were gnu stdc++ specific, thereby tying gcc to a particular C++ library. And I thought this was generally undesireable, as opposed to being undesireable just for me. Always willing to be corrected. :-) So to clarify my understanding, the __cxa symbols being emitted by cc1plus are part of the C++ standard, and are missing from Dinkumware, yes? Cheers, and thanks again. GP Joe Buck said: > On Tue, May 20, 2003 at 02:11:02PM -0000, gp@qnx.com wrote: > > Here is the output of a simple C++ compile using gcc-3.2.3 and our port of the > > Dinkum libcpp. The Dinkumware implements 'new' and 'delete', but it has not > > presented as a problem yet, except if we try to use the libsupc++ to resolve > > the cxa symbols. Which is why I thought that splitting the cxa stuff into a > > libcxa (that would also be linked into the libsupc++) would work. The symbols > > in libsupc++ that conflict (multiple definitions) are: > > > > std::terminate() > > std::unexpected() > > std::set_terminate(void (*)()) > > std::set_unexpected(void (*)()) > > So evidently Dinkumware is also trying to provide some exception handling > support, not just new and delete. > > > It seems to me that cc1plus should not be emitting libstdc++ specific symbols, > > thereby assuming that the c++ libs being used are only going to be GNU > > libstdc++. Failing that, providing a libcxa of some kind would be very helpful. > > All the symbols that cc1plus exports should be (and are, as far as I know) > provided by libsupc++. That is, any symbol emitted by the compiler itself > should be satisfied by that mini-library. You should not need libstdc++. > > You are running into trouble because Dinkumware > is attempting to provide some but not all C++ support. I think you'd be > better off stripping the conflicting symbols from Dinkumware and using > the libsupc++ symbols. If you don't, you risk trouble later, because the > compiler may be assuming properties of the support routines that aren't > obeyed by Dinkumware. Supporting the Dinkumware library was never a > GNU C++ goal, so if you want to make it work, great, but asking for a > redesign of libstdc++ for such a narrow goal doesn't seem reasonable to me. > --