This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: C++ demangler horrors
- From: Alexandre Oliva <aoliva at redhat dot com>
- To: Nathanael Nerode <neroden at twcny dot rr dot com>
- Cc: gcc-patches at gcc dot gnu dot org
- Date: 08 Jul 2003 01:54:03 -0300
- Subject: Re: C++ demangler horrors
- Organization: GCC Team, Red Hat
- References: <20030708041953.GA565@doctormoo>
On Jul 8, 2003, Nathanael Nerode <neroden@twcny.rr.com> wrote:
> Alex said:
>> 1) when libiberty is configured for the build or host machine, just
>> check whether a C++ compiler is there, and use the result to decide
>> which demangler to build, and that's it.
> This is precisely what I would like to avoid. :-p For the build machine
> it's fine since the build libraries never get installed, of course. For
> the host, I want the demangler chosen *not* to be dependent on random
> features of the build environment.
Agreed. Let's change the proposal to require a flag to configure
without a pre-existing C++ compiler for the host, then.
>> 2) when libiberty is configured for the target, do *not* test for a
>> C++ compiler. Instead, get configure-target-libiberty to depend on
>> configure-target-libstdc++-v3 (does this introduce any cycles?),
> No.
> Does merely configuring libstdc++-v3 without building it give us the
> needed header files in the correct arrangement?
I'd like to believe so. libstdc++-v3's configure creates some links
and scripts that, I *think* are enough for C++ code to be compiled.
Some libstdc++er please correct me if I'm mistaken. Even if I am, it
would be nice if it could be changed such that we could do this.
> That would be mildly
> surprising to me. And if it does, why can't we just pull them 'raw' out
> of the source directory
Because not all of them are in the source directory. There are some
platform dependencies deep inside it, that are adjusted only in the
build tree.
>> and just assume the C++ compiler is good enough to build the
>> C++ demangler into libiberty. We still need some logic for the
>> case of a C-only build, but I think this approach might work.
> And for the cases when build!=target.
Then we already need a working build-x-target C++ compiler to build
libstdc++ anyway, so same difference.
> (Although that would fit in with one of my crazier plans, involving
> a 3-staged build for Canadian crosses.)
I don't see why you'd need a host libstdc++ for that.
Hmm... Ok, I think I do. I had other ideas on how to implement this,
but yours sound better.
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{redhat.com, gcc.gnu.org}
CS PhD student at IC-Unicamp oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist Professional serial bug killer