Bug#114795: gcc-3.0: Weird behaviour with -I/usr/include

[Daniel Jacobowitz <dan@debian.org>]

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