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
next prev 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