RFA: Please review the new C++ demangler patch

[Zack Weinberg]

"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".

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
to build libiberty after libstdc++, which may be a problem on some
targets.

> 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.)

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

Why?

zw