This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: C++ demangler horrors


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]