This is the mail archive of the
libstdc++@gcc.gnu.org
mailing list for the libstdc++ project.
Re: [libstdc++] Make use of runtime demangler
- From: Benjamin Kosnik <bkoz at redhat dot com>
- To: Mark Mitchell <mark at codesourcery dot com>
- Cc: Carlo Wood <carlo at alinoe dot com>, Phil Edwards <phil at jaj dot com>, "libstdc++ at gcc dot gnu dot org" <libstdc++ at gcc dot gnu dot org>
- Date: Mon, 1 Apr 2002 10:27:50 -0800 (PST)
- Subject: Re: [libstdc++] Make use of runtime demangler
> If your demangler is better, we can replace the one in libiberty with
> yours. Or, we can take the one in libiberty and fix the problems you've
> found. We certainly should end up with only one demangler at the end
> of the day.
Ok. So, the idea of taking the demangler out of libiberty is still sound,
regardless of if the definition of __cxa_demangle is to remain the same as
it is now?
Great.
> We should probably remove the IN_LIBGCC2 stuff. In the intial version of
> this stuff (this is before libsupc++, when runtime support for C++ was in
> libgcc) that made sense. Now, it doesn't.
Should __cxa_demangle just be in a separate file? Or, should
IN_GLIBCPP_V3 stay and just IN_LIBGCC2 get removed?
> 1) Those two files do not build warning-free because in the v3 build,
> -DHAVE_CONFIG_H is not passed (thus the headers for malloc and whatnot
> are not included) because we can't give it the config.h from libiberty.
> I played with building a symlink to libiberty's config.h but I don't
> know the multilibs scenario well enough. Help is requested. For now,
> we pass -Wno-error in the special build rules.
libmath uses libstdc++'s config.h. Perhaps these files could as well?
-benjamin