This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: libstdc++-v3/std_cstddef.h's #include_next x libg++
- To: Alexandre Oliva <aoliva at redhat dot com>
- Subject: Re: libstdc++-v3/std_cstddef.h's #include_next x libg++
- From: Benjamin Kosnik <bkoz at redhat dot com>
- Date: Wed, 9 Aug 2000 00:49:11 -0700 (PDT)
- cc: gcc at gcc dot gnu dot org, libstdc++ at sources dot redhat dot com, ncm at zembu dot com
> #include_next <stddef.h>
>
> Since the preprocessor apparently only searches for stddef.h in
> directories that appear in the search list after the one in which it
> found the current header, it fails.
Did the pre-processor's behavior WRT #include_next change recently? I'm
also noticing broken/weird behavior, but relating to the
--enable-cshadow-header stuff.
Then again, this could be something completely different, relating to
changes in the shadow-headers script...
Anyway.
The libstdc++-v3 header files are constructed in a more-funky-than-usual
way because of an attempt (currently broken) to squester the C bits into
some kind sanity for C++.
Background details can be found on Nathan's web page:
http://www.cantrip.org/cheaders.html
> output by libstdc++-v3's
> mkcheck in `-isystem' (so they'd always be searched before directories
> introduced by -B)?
Hmm. Does your problem manifest itself without trying to build libg++, ie
when running libstdc++-v3's 'mkcheck' script, which is run via 'make
check-target-libstdc++-v3' ??
I'm a bit confused as to what your exact problem is: can you provide a
bit more detail please?
> Maybe std_cstddef.h shouldn't be using
> #include_next to include a header with a different name?
Hmm. Dunno. . . At some point, Nathan (or somebody) needs to get
--enable-cshadow-headers working again. That way the #include_next stuff
will actually be useful again.....
-benjamin