public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: Joe Buck <jbuck@synopsys.com>
To: gp@qnx.com
Cc: gcc@gcc.gnu.org
Subject: Re: libsupc++,  _cxa  references, and Dinkum libcpp
Date: Tue, 20 May 2003 17:34:00 -0000	[thread overview]
Message-ID: <20030520094658.A12888@synopsys.com> (raw)
In-Reply-To: <200305201411.h4KEB2j08838@webmail.ott.qnx.com>; from gp@qnx.com on Tue, May 20, 2003 at 02:11:02PM -0000

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.

  reply	other threads:[~2003-05-20 16:47 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-05-16 21:24 gp
2003-05-16 23:55 ` Joe Buck
2003-05-20 16:19   ` gp
2003-05-20 17:34     ` Joe Buck [this message]
2003-05-20 18:38       ` gp
2003-05-20 18:38         ` Joe Buck
2003-05-20 19:37           ` gp
2003-05-20 18:41         ` Andrew Pinski

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=20030520094658.A12888@synopsys.com \
    --to=jbuck@synopsys.com \
    --cc=gcc@gcc.gnu.org \
    --cc=gp@qnx.com \
    /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: link
Be 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).