This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: RFA: Please review the new C++ demangler patch
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.