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