PATCH: Support the new demangler written in C++

[H. J. Lu]

On Mon, Jul 07, 2003 at 10:06:18PM -0300, Alexandre Oliva wrote:
> On Jul  7, 2003, "H. J. Lu" <hjl@lucon.org> wrote:
> 
> > I updated my demangler patch. I don't like the idea to have a second
> > <vector> when there is one in libstdc++ already.
> 
> Me, I don't like the idea of having a separate directory changing the
> contents of another.  Consider `make install'.  This may build
> libiberty, install libiberty, then build the demangler, and then fail

I don't believe you can do "make install" without doing "make" first.
In binutils, I got

# make install
/bin/sh /export/linux/src/binutils/binutils/mkinstalldirs /usr/local /usr/local
/bin/sh: line 1: cd: bfd: No such file or directory

> to install it.  Consider something that naively depends on
> all-libiberty, like libstdc++: it may be sufficiently unlucky that,
> when it links with libiberty, it's being modified, or is no longer
> there.  Your patch doesn't fix that.  I don't see how it can possibly
> be fixed without creating one library when libiberty is first
> built, and a *different* library when we build the demangler.
> 
> Assuming this is supposed to go in anyway, please make sure you spell
> TARGET correctly (it's TERGET in your patch), and move
> ALL_TARGET_LIBIBERTY closer to the other ALL*_LIBIBERTY macros.  Also,
> make sure they expand to not only maybe-all*-demangler, but also
> maybe-all*-libiberty.  The way it is now, should the demangler
> directory not be there, it wouldn't build libiberty at all.

I will fix those.

> 
> Also, I'd much rather have demangler be a subdirectory of libiberty,
> that a new top-level directory.  It would be nice if we could use
> libiberty/demangler as one of the build/host/target directories.

It will be very ugly to express target dependencies among libiberty,
libstdc++ and libiberty/demangler.

> 
> That said, I'm coming to the conclusion that we should probably bite
> the bullet and move demangler completely out of libiberty, or build
> a libiberty-old-demangler pass first, that creates a different
> library, and the real libiberty with the demangler later, when a C++
> compiler is ready.  This won't avoid the need for changing Makefiles
> to reference the other libiberty, though, but it's needed for
> parallel-make safety.
> 

H.J.