This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [libstdc++] Make use of runtime demangler
- From: Franz Sirl <Franz dot Sirl-kernel at lauterbach dot com>
- To: Phil Edwards <phil at jaj dot com>
- Cc: Mark Mitchell <mark at codesourcery dot com>,"libstdc++ at gcc dot gnu dot org" <libstdc++ at gcc dot gnu dot org>,"gcc-patches at gcc dot gnu dot org" <gcc-patches at gcc dot gnu dot org>
- Date: Wed, 1 May 2002 02:03:54 +0200
- Subject: Re: [libstdc++] Make use of runtime demangler
- References: <20020329182924.A31493@disaster.basement.lan> <200204300020.42281@enzo.bigblue.local> <20020430194134.A3286@disaster.basement.lan>
On Wednesday 01 May 2002 01:41, Phil Edwards wrote:
> On Tue, Apr 30, 2002 at 12:20:42AM +0200, Franz Sirl wrote:
> > > So, before we start reintroducing any of that, I have to wonder whether
> > > the same problems -- presumably problems with shadow headers -- will
> > > still occur. Probably not a fair question, since so much of our header
> > > setup has changed in the last 18 months.
> >
> > But why would one remove the whole of $(DEFS) just for the sake of
> > removing a single include?
>
> I have no idea. But I don't recall what problems we were experiencing at
> the time. (It was 18-odd months ago, I can't even remember when to go to
> lunch from day to day.)
Heh :-)
> > Simply setting $(DEFS) as required in Makefile.am seems like
> > a lot simpler approach to me. Do you want to go with such an solution? I
> > would additionally add
> >
> > # we need DEFS without -I$(srcdir)
> > DEFS = @DEFS@ -I. -I..
> >
> > to Makefile.am in my patch then.
>
> Actually, we shouldn't even need the -I switches, since we're not adding
> them back in anywhere else, I /think/. There are probably some multilib
> issues here.
We need at least -I.. to get at config.h and I don't see any multilib issues
here, since -I.. will be $target_alias/$multilibdir/libstdc++-v3/
> I stuck the DEFS definition as shown below; it seemed to make the most
> sense there. Would you be willing to add that change to your patch and
> retest? Probably a retest isn't necessary, but I'm once-bitten-twice-shy
> when playing with variables that can be automatically set by automake.
> I think the patch can go in after that.
I'll retest with the -I.. added, seems like I'm doing nothing but bootstraps
the whole day currently :-).
Franz.