From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5437 invoked by alias); 20 May 2003 16:47:36 -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 5227 invoked from network); 20 May 2003 16:47:30 -0000 Received: from unknown (HELO piper.synopsys.com) (204.176.21.194) by sources.redhat.com with SMTP; 20 May 2003 16:47:30 -0000 Received: (from jbuck@localhost) by piper.synopsys.com (8.11.6/8.11.6) id h4KGkw312926; Tue, 20 May 2003 09:46:58 -0700 Date: Tue, 20 May 2003 17:34:00 -0000 From: Joe Buck To: gp@qnx.com Cc: gcc@gcc.gnu.org Subject: Re: libsupc++, _cxa references, and Dinkum libcpp Message-ID: <20030520094658.A12888@synopsys.com> References: <20030516165135.A12185@synopsys.com> <200305201411.h4KEB2j08838@webmail.ott.qnx.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <200305201411.h4KEB2j08838@webmail.ott.qnx.com>; from gp@qnx.com on Tue, May 20, 2003 at 02:11:02PM -0000 X-SW-Source: 2003-05/txt/msg01878.txt.bz2 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.