RFA: Please review the new C++ demangler patch

[H. J. Lu]

On Wed, Jun 25, 2003 at 09:46:23AM -0700, Zack Weinberg wrote:
> Benjamin Kosnik <bkoz@redhat.com> writes:
> 
> >> Me too. But I also want a correct C++ demangler.
> >
> > I would like to see support for C++ predicated on the existence of C++.
> > I don't think this is unreasonable.
> 
> Having the C++ compiler around should not be a problem.  I'm worried
> about the requirement for libstdc++, which (as discussed upthread)
> produces nasty circular build dependencies that I am not convinced
> have been adequately addressed.

The circular build dependency is only a concern for the target
demangler library. There are

configure-target-demangler: maybe-all-target-libstdc++-v3
all-target-demangler: configure-target-demangler

in Makefile.tpl. That is we build the target demangler after libstdc++
is available.

> Rewriting the demangler not to use <vector> is hard, OK.  How about
> embedding a mini <vector> in the demangler?  Same same for whatever it
> needs from libsupc++.  Needs careful handling of symbols.  And then
> maybe the demangler should be pulled out of libiberty and given its
> own library, we ought to be able to nail down the ABI and make a
> proper shared object...  Ideally exposes no symbols that aren't extern "C".
> 

It is only useful if the C++ compiler for build doesn't have a working
<vector>. The demangler configure checks if the C++ compiler can
compile the demangler and link the resulting demangler library with
the C compiler before enabling it. It doesn't handle the case where
<vector> exists, but doesn't work right. But I don't think it should
be a factor here. I don't see why any gcc developers should spend
time to help broken C++ compilers.


H.J.