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

[Richard Atterer <atterer@debian.org>]

On Sun, Oct 07, 2001 at 07:05:04PM -0400, Daniel Jacobowitz wrote:
> On Sun, Oct 07, 2001 at 08:57:22PM +0200, Richard Atterer wrote:
> > I encountered some very strange behaviour when using
> > -I/usr/include. Obviously, it doesn't make much sense to supply
> > this switch on the command line, but in any case gcc's reaction is
> > wrong. (I came across this because libwww-config happens to
> > include -I/usr/include in its --cflags output.)
> 
> That's a bug in libwww-config; please file it.

No need - I think I'll adopt libwww from Takuo KITAME... :)

> 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:

> echo '#include <string>' >x.cc 
> touch string.hh
> g++-3.0 -I/usr/include -c x.cc -o x.o

Also, libstdc++3-dev doesn't provide any string.h file which could
override /usr/include/string.h. I believe this bug is unrelated to
what the info manual talks about.

(BTW, the above works fine with gcc-2.95.)

Bye,

  Richard

-- 
  __   _
  |_) /|  Richard Atterer
  | \/¯|  http://atterer.net
  ¯ ´` ¯