On Mon, Oct 08, 2001 at 04:44:11PM +0200, Richard Atterer wrote: > > It's documented in the gcc manual that you should not do this. > > Somewhere. I don't immediately see where :( > > I've found it in the node "Interoperation": > > * Use of `-I/usr/include' may cause trouble. > > Many systems come with header files that won't work with GCC > unless corrected by `fixincludes'. The corrected header files go > in a new directory; GCC searches this directory before > `/usr/include'. If you use `-I/usr/include', this tells GCC to > search `/usr/include' earlier on, before the corrected headers. > The result is that you get the uncorrected header files. > > Instead, you should use these options (when compiling C programs): > > -I/usr/local/lib/gcc-lib/TARGET/VERSION/include -I/usr/include > > For C++ programs, GCC also uses a special directory that defines > C++ interfaces to standard C subroutines. This directory is meant > to be searched _before_ other standard include directories, so > that it takes precedence. If you are compiling C++ programs and > specifying include directories explicitly, use this option first, > then the two options above: > > -I/usr/local/lib/g++-include > > That explanation doesn't quite make sense for this bug - surely the > headers in /usr/include do not need to be corrected by "fixincludes"?! > Furthermore, notice the weird circumstances necessary to provoke it; a > file named _string.hh_ (NOT string.h) in the _current_ directory:
I knew you'd find that :) The whole section seems to be obsolete. This is actually a problem with #include_next. I recommend you search the mailing list archives for gcc-bugs about this. -- Daniel Jacobowitz Carnegie Mellon University MontaVista Software Debian GNU/Linux Developer