problem/bug with include directory order

["Christian Ehrhardt" <ehrhardt at mathematik dot uni-ulm dot de>]

Hi,

I just noticed that any current version of gcc gives strange compiler
errors on my system when working with curses and I believe that there
is a Bug with the priority of the directory that contains fixed header
files.

The situation is this:
A sparc-sun-solaris2.9 host has the Sun supplied curses headers installed
in /usr/include and ncurses headers installed in /usr/local/include.
Now gcc came to the conclusion that it needs to fix SOME of the
vendor supplied curses headers in /usr/include. These fixed header files
are placed into /usr/local/lib/gcc-lib/sparc-sun-solaris2.9/3.2/include.

Unfortunately due to reasons that I don't understand the search order for
include files as reported by gcc -v is this:
 /usr/local/lib/gcc-lib/sparc-sun-solaris2.9/3.2/include
 /usr/local/include
 /usr/include

Now if I include curses.h (which needed fixing) the file is found in
/usr/local/lib/gcc-lib/sparc-sun-solaris2.9/3.2/include, i.e. we use
the fixed vendor supplied header file. Now curses.h includes another file
(unctrl.h). There are two incompatible versions of this file, one that is
vendor supplied and one that came with ncurses. However, unctrl.h didn't
need fixing and consequently there is no unctrl.h in 
/usr/local/lib/gcc-lib/sparc-sun-solaris2.9/3.2/include. This means that
unctrl.h from /usr/local/include is used instead. The result is that
the vendor supplied curses.h is used with unctrl.h from ncurses and this
combination doesn't compile.

IMHO this is a bug. The expected "semantic" of the fixed include files
should be exactly as if the original file had been replaced with the fixed
version, i.e: First check for the include file in the normal directories then
see if that specific include file needed fixing and use the fixed version
instead. This can be achieved if the directory with the fixed header files
is searched immediatly before the directory with the original files which
is not the case on my system.

Comments? If this is a bug I'll file a PR with GNATS. If it is not a bug
is there some spec-file magic that I can do to get the search order that
I want, i.e.:
 /usr/local/include
 /usr/local/lib/gcc-lib/sparc-sun-solaris2.9/3.2/include
 /usr/include

Here's the complete output of gcc -v which also shows that one instance
of /usr/local/include is deleted from the list in include directories as
a duplicate.

Reading specs from /usr/local/bin/../lib/gcc-lib/sparc-sun-solaris2.9/3.2/specs
Configured with: /export/local/manager/playground/ULMgcc32/src/gcc-3.2/configure --with-ld=/usr/local/bin/ld --with-gnu-ld --with-as=/usr/local/bin/as --with-gnu-as --prefix=/usr/local/
Thread model: posix
gcc version 3.2
 /usr/local/bin/../lib/gcc-lib/sparc-sun-solaris2.9/3.2/cc1 -lang-c -v -iprefix /usr/local/bin/../lib/gcc-lib/sparc-sun-solaris2.9/3.2/ -D__GNUC__=3 -D__GNUC_MINOR__=2 -D__GNUC_PATCHLEVEL__=0 -D__GXX_ABI_VERSION=102 -Dsparc -Dsun -Dunix -D__svr4__ -D__SVR4 -D__PRAGMA_REDEFINE_EXTNAME -D__sparc__ -D__sun__ -D__unix__ -D__svr4__ -D__SVR4 -D__PRAGMA_REDEFINE_EXTNAME -D__sparc -D__sun -D__unix -Asystem=unix -Asystem=svr4 -D__NO_INLINE__ -D__STDC_HOSTED__=1 -D__SIZE_TYPE__=unsigned int -D__PTRDIFF_TYPE__=int -D__WCHAR_TYPE__=long int -D__WINT_TYPE__=long int -D__GCC_NEW_VARARGS__ -Acpu=sparc -Amachine=sparc curs.c -quiet -dumpbase curs.c -version -o /tmp/ccJR61gD.s
GNU CPP version 3.2 (cpplib) (sparc ELF)
GNU C version 3.2 (sparc-sun-solaris2.9)
	compiled by GNU C version 3.2.
ignoring nonexistent directory "/usr/local/sparc-sun-solaris2.9/include"
ignoring nonexistent directory "/usr/local/sparc-sun-solaris2.9/include"
ignoring duplicate directory "/usr/local/include"
ignoring duplicate directory "/usr/local/lib/gcc-lib/sparc-sun-solaris2.9/3.2/include"
#include "..." search starts here:
#include <...> search starts here:
 /usr/local/lib/gcc-lib/sparc-sun-solaris2.9/3.2/include
 /usr/local/include
 /usr/include
End of search list.
In file included from /usr/local/lib/gcc-lib/sparc-sun-solaris2.9/3.2/include/curses.h:787,
                 from curs.c:1:
/usr/local/include/unctrl.h:57: syntax error before "char"
/usr/local/include/unctrl.h:57: conflicting types for `unctrl'
/usr/local/lib/gcc-lib/sparc-sun-solaris2.9/3.2/include/curses.h:296: previous declaration of `unctrl'

   regards  Christian 

-- 
THAT'S ALL FOLKS!