C++ demangler horrors

[H. J. Lu]

On Sat, Jun 28, 2003 at 11:37:17AM +0200, Gabriel Dos Reis wrote:
> "H. J. Lu" <hjl@lucon.org> writes:
> 
> | Ironically, this mini <vector> is not needed by binutils nor gdb. It is
> | used to build the target libiberty for gcc since libiberty is built before
> | libstdc++ which contains a <vector>. My approach may not be as elegant as
> | some people want, but it works and doesn't require another <vector>. I am
> | not sure which one is worse.
> 
> If it is not necessary then there is no need to add it.
> 

My patch doesn't requrie it. But some people don't like the way I solved
the problem with

ar -d ....
ar rc ....

in the new demangler Makefile to replace the old demangler in libiberty.a.
I can change my patch to do the following:

1. Add a new target in libiberty Makefile, demangler, which does:

	a. Symlink the new demangler
	b. Build it.
	c. Replace the old one with

		ar -d libiberty.a cp-demangle.o
		ar rc libiberty.a demangle.o

2. Change the new demangler configure file to do

	a. If there is no libiberty directory, build the standalone demangler.
	b. Otherwise, create a Makefile file simple does

		all:
			$(MAKE) -C ../libiberty demangler

		.DEFAILT:
			@true

3. Change the top level dependency such that targets which used to depend on
libiberty, now depend on demangler, demangler depends on libiberty and
libstdc++ if it is needed. Please keep in mind that only demangler for target
needs libstdc++ for target. I don't believe it has much impact on parallel
build.

The difference between my original patch and this one is the real work is
moved from demangler to libiberty.


H.J.