Re: RFA: Please review the new C++ demangler patch

["H. J. Lu" <hjl at lucon dot org>]

On Wed, Jun 25, 2003 at 12:30:27PM -0700, Zack Weinberg wrote:
> "H. J. Lu" <hjl@lucon.org> writes:
> 
> > On Wed, Jun 25, 2003 at 11:07:30AM -0700, Zack Weinberg wrote:
> >> "H. J. Lu" <hjl@lucon.org> writes:
> >> 
> >> >> 
> >> >> So you want to have two copies of the demangler?  Or how do you
> >> >> propose to get the demangler into libstdc++?
> >> >
> >> > There are always 2 C++ demanglers. One is in libiberty and the other
> >> > is in libstdc++.
> >> 
> >> There's always going to be two copies of the object, since it is
> >> expected to appear in both libraries.  I'm talking about the source
> >> code.  Are there two copies of the source code?  If there are, explain
> >> how you propose to guarantee that they are kept in sync.  If there are
> >> not, explain how you get the object file included in both libiberty
> >> and libstdc++ without introducing circular build dependencies.
> >
> > There will be only one source with my patches applied. Both libiberty
> > and libstdc++ will use the one in demangler. During the demangler
> > build, it will remove the old one in libiberty and put the new one
> > in.
> 
> I don't understand what you mean by "remove the old one".

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

> 
> Why not just leave the new demangler where it is, in libstdc++, and
> have libiberty's Makefile refer to the code from there?  I don't see a
> need to introduce a new top level directory.  You would, however, have

See below.

> to build libiberty after libstdc++, which may be a problem on some
> targets.

I said build "demangler", not libiberty, after libstdc++.

> 
> > libstdc++ will make symlinks of source codes from demangler during
> > build.
> 
> How does this work on a host that doesn't have symlinks?  (You could
> just put a relative path to the file in the demangler directory in the
> Makefile.)

It uses $(LN_S), which should do the right thing. FWIW, we did the
same thing when libstdc++ used the old demangler in libiberty. I don't
see how it becomes an issue today.

> 
> > In fact, the object files in libiberty and libstdc++ are different
> > since they are compiled with different compiler options.
> 
> Why?

The one in libiberty only supports the C interface without C++ support,
like RTTI and exeception. Also it uses its own allocator and dynstring
so that it can be used as a C function. Otherwise, you can put it in
libiberty. But you don't want to do that in libstdc++.


H.J.