Mirror of the gdb mailing list
 help / color / mirror / Atom feed
From: Nathanael Nerode <neroden@twcny.rr.com>
To: Alexandre Oliva <aoliva@redhat.com>
Cc: Gabriel Dos Reis <gdr@integrable-solutions.net>,
	Andrew Cagney <ac131313@redhat.com>,
	fche@redhat.com, gdb@sources.redhat.com,
	binutils@sources.redhat.com, hjl@lucon.org
Subject: Re: FYI: A new C++ demangler
Date: Wed, 16 Jul 2003 17:12:00 -0000	[thread overview]
Message-ID: <3F158757.30507@twcny.rr.com> (raw)
In-Reply-To: <oroezv8vec.fsf@free.redhat.lsd.ic.unicamp.br>

Alexandre Oliva wrote:
> On Jul 15, 2003, Gabriel Dos Reis <gdr@integrable-solutions.net> wrote:
>>Yes.  Apparently Nathanael doesn't seem to understand that C++
>>can be used productively for system programming.
No, I understand that.  Why do people keep missing the point?  Let me 
try again.

Adding the C++ demangler to libiberty adds a new build requirement, C++, 
to anything which uses libiberty.  DJ, the libiberty maintainer, has 
said that this is not OK with him because it does not satisfy the goals 
of libiberty.

HJ's plan of having two versions of libiberty, one with the 'new' 
demangler and one with the 'old' demangler, selected magically at 
build-time, is a very, very bad idea because it's confusing.  I don't 
care whether they're link-compatible; it still means two versions of 
libiberty pretending to be the same version.  It's designed to cause 
confusion and untraceable bug reports.

Or if the demangler is outside libiberty, it means GDB (and anything 
else using the new demangler) requires C++ to build, which is again 
*fine with me*.  But apparently it's *not* acceptable to the GDB people. 
  Go talk to them about whether "C++ can be used productively for system 
programming", if you like.

> I don't think the issue is about using C++ for system programming.
> The issue is about having to force every user of libiberty to start
> linking programs that link with libiberty using $(CXX) instead of just
> $(CC).  This would be a very incompatible and, IMHO, undesirable
> change.
It's not just linking, it's building as well.  See above.

If adding C++ as a build requirement is considered acceptable by all the 
projects using libiberty (which includes stuff outside gcc/src), then 
the C++ demangler can be put in libiberty.

If adding C++ as a build requirement is considered acceptable by all the 
projects in gcc/src which want the new demangler, then the C++ demangler 
can be put in as a separate directory.

If adding C++ as a build requirement is *not* considered acceptable by 
any *one* of them, we can't.  It's as simple as that, and it's nothing 
to do with me.  Feel free to convince the projects in GCC and SRC that 
they want to add C++ as a build requirement.

The only thing I am *personally* strongly against is the stupid scheme 
for silently building different versions of libiberty (or, indeed, GDB 
or binutils) under the same name depending on the build environment.  I 
even said that multiple versions would be fine by me if they were 
controlled by an explicit option, rather than implicit characteristics 
of the build environment.

--Nathanael


  parent reply	other threads:[~2003-07-16 17:12 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-07-12 18:02 Nathanael Nerode
2003-07-15 16:17 ` Andrew Cagney
2003-07-15 18:03   ` Gabriel Dos Reis
2003-07-15 19:02     ` Andrew Cagney
2003-07-15 19:03     ` Alexandre Oliva
2003-07-15 19:16       ` H. J. Lu
2003-07-15 19:49         ` Alexandre Oliva
2003-07-15 19:55           ` H. J. Lu
2003-07-15 22:30             ` Alexandre Oliva
2003-07-15 23:14               ` H. J. Lu
2003-07-16  2:31                 ` Alexandre Oliva
2003-07-16  3:21                 ` Ian Lance Taylor
2003-07-16 17:12       ` Nathanael Nerode [this message]
2003-07-15 19:16     ` Ian Lance Taylor
2003-07-15 19:23       ` H. J. Lu
2003-07-15 20:05       ` DJ Delorie
  -- strict thread matches above, loose matches on Subject: below --
2003-07-11  0:36 Michael Elizabeth Chastain
2003-07-10 21:57 Michael Elizabeth Chastain
2003-07-10 15:42 Michael Elizabeth Chastain
2003-07-10 15:51 ` H. J. Lu
2003-07-10 16:38 ` Ian Lance Taylor
2003-07-10 14:36 H. J. Lu
2003-07-10 14:40 ` Ian Lance Taylor
2003-07-10 14:54   ` H. J. Lu
2003-07-10 15:28 ` David Carlton
2003-07-10 15:36   ` H. J. Lu
2003-07-10 15:44     ` David Carlton
2003-07-10 20:57 ` Mark Kettenis
2003-07-10 21:17   ` Andrew Cagney
2003-07-10 21:44     ` H. J. Lu
2003-07-10 22:58     ` Frank Ch. Eigler
2003-07-10 23:19       ` Andrew Cagney
2003-07-10 21:22   ` DJ Delorie

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=3F158757.30507@twcny.rr.com \
    --to=neroden@twcny.rr.com \
    --cc=ac131313@redhat.com \
    --cc=aoliva@redhat.com \
    --cc=binutils@sources.redhat.com \
    --cc=fche@redhat.com \
    --cc=gdb@sources.redhat.com \
    --cc=gdr@integrable-solutions.net \
    --cc=hjl@lucon.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: 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