RFA: Please review the new C++ demangler patch

[H. J. Lu]

On Wed, Jun 25, 2003 at 04:13:05PM -0700, Zack Weinberg wrote:
> "H. J. Lu" <hjl@lucon.org> writes:
> 
> > I don't want to force the change of the build order between libiberty
> > and libstdc++ in this patch. It may cause other problems.
> 
> So do it as a separate patch *first*.

This is a totally separate issue. You should start a new thread.

> 
> > Besides a separate demangler directory/library is eaiser to maintain.
> 
> And this remove-and-replace tactic is asking for trouble - e.g. if
> anyone ever decides to libtoolize libiberty.

demangler uses libtool. It is trivial to deal with libtoolized
libiberty. It can be synced with libiberty easily.

> 
> You can have your own directory for the demangler, but then it has to
> be built before libiberty and libiberty has to pick up the .o files.
> 

You should ask Carlo Wood if he wants to maintain demangler in
libiberty. Also you should get OK to use C++ in libiberty first.


> >> and then we can GET RID OF the old demangler that doesn't work?
> >
> > Some people may not have C++ compiler. They can still use the old one.
> > libiberty has never required a C++ compiler to compile.
> 
> If they don't have a C++ compiler they don't need a C++ demangler
> either.

That is not true. binutils uses C++ demangler. You can have .o files
compiled from C++ code. But you don't need to use a C++ compiler. The
new demangler is an example.


> 
> >> > We have done that, but in .o files. You can have use both the demangler
> >> > in libiberty and the one in libstdc++ in the same program.
> >> 
> >> Cleaner to do it at the source level, I think.
> >
> > It is very hard.
> 
> Getting things right is often hard.
> 

You may wind up writing a new libstdc++, which I have no desire to do.
I don't see why any gcc developers should spend time on it either.


H.J.