libstdc++/3465: Using option -I/usr/include breaks bits/std_c*.h

[brad dot king at kitware dot com]

>Number:         3465
>Category:       libstdc++
>Synopsis:       Using option -I/usr/include breaks bits/std_c*.h
>Confidential:   no
>Severity:       non-critical
>Priority:       medium
>Responsible:    unassigned
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Thu Jun 28 12:16:00 PDT 2001
>Closed-Date:
>Last-Modified:
>Originator:     Brad King
>Release:        gcc-3.0
>Organization:
>Environment:
Linux 2.2.18 i686
>Description:
If the include path "/usr/include" is added with a -I option, it is moved to 
the front of the search path for include files, and then appears before 
"PREFIX/include/g++-v3".  This breaks the #include_next <> lines in headers like "PREFIX/include/g++-v3/bits/std_cstdio.h" (so files like stdio.h are reported as not found).
>How-To-Repeat:
Build a program which consists of the line "#include <iostream>" using the command line "g++ -I/usr/include -c file.cxx".

Adding "-v" produces output like this, which shows the change in include path ordering (normally /usr/include occurs at the end of the path):

Reading specs from /home/gcc30/inst/lib/gcc-lib/i686-pc-linux-gnu/3.0/specs
Configured with: ../gcc30/configure --prefix=/home/gcc30/inst --enable-languages=c,c++ --disable-nls
Thread model: single
gcc version 3.0
 /home/gcc30/inst/lib/gcc-lib/i686-pc-linux-gnu/3.0/cc1plus -v -I/usr/include -D__GNUC__=3 -D__GNUC_MINOR__=0 -D__GNUC_PATCHLEVEL__=0 -D__ELF__ -Dunix -Dlinux -D__ELF__ -D__unix__ -D__linux__ -D__unix -D__linux -Asystem=posix -D__NO_INLINE__ -D__STDC_HOSTED__=1 -D_GNU_SOURCE -Acpu=i386 -Amachine=i386 -Di386 -D__i386 -D__i386__ -D__tune_i686__ -D__tune_pentiumpro__ t.cxx -D__GNUG__=3 -D__GXX_DEPRECATED -D__EXCEPTIONS -D__GXX_ABI_VERSION=100 -quiet -dumpbase t.cxx -version -o /tmp/cc3tnGOm.s
GNU CPP version 3.0 (cpplib) (i386 Linux/ELF)
GNU C++ version 3.0 (i686-pc-linux-gnu)
	compiled by GNU C version 3.0.
ignoring duplicate directory "/usr/local/include"
ignoring duplicate directory "/usr/include"
#include "..." search starts here:
#include <...> search starts here:
 /usr/include
 /usr/local/include
 /home/gcc30/inst/include/g++-v3
 /home/gcc30/inst/include/g++-v3/i686-pc-linux-gnu
 /home/gcc30/inst/include/g++-v3/backward
 /home/gcc30/inst/lib/gcc-lib/i686-pc-linux-gnu/3.0/include
 /home/gcc30/inst/i686-pc-linux-gnu/include
End of search list.
In file included from /home/gcc30/inst/include/g++-v3/cstdio:31,
                 from /home/gcc30/inst/include/g++-v3/i686-pc-linux-gnu/bits/c++io.h:35,
                 from /home/gcc30/inst/include/g++-v3/bits/fpos.h:39,
                 from /home/gcc30/inst/include/g++-v3/bits/std_iosfwd.h:41,
                 from /home/gcc30/inst/include/g++-v3/bits/std_ios.h:39,
                 from /home/gcc30/inst/include/g++-v3/bits/std_ostream.h:39,
                 from /home/gcc30/inst/include/g++-v3/bits/std_iostream.h:40,
                 from /home/gcc30/inst/include/g++-v3/iostream:31,
                 from t.cxx:1:
/home/gcc30/inst/include/g++-v3/bits/std_cstdio.h:41:24: stdio.h: No such file or directory
In file included from /home/gcc30/inst/include/g++-v3/cstdio:31,

>Fix:
I have not looked into why the std_c*.h headers use #include_next, but if they were #include, this particular problem would disappear.
>Release-Note:
>Audit-Trail:
>Unformatted: