This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: RFA: Please review the new C++ demangler patch
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.