Bug#114795: gcc-3.0: Weird behaviour with -I/usr/include
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:
> 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
Daniel Jacobowitz Carnegie Mellon University
MontaVista Software Debian GNU/Linux Developer