This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
default system path questions
- From: Edward Peschko <horos11 at gmail dot com>
- To: gcc at gcc dot gnu dot org
- Date: Thu, 23 Dec 2010 14:17:34 -0800
- Subject: default system path questions
All,
I found much to my dismay today that -I doesn't always work as
intuited. Namely, if I set CFLAGS to:
-I/path/to/gcc/include
where the default system path is:
/path/to/gcc/lib/gcc/i686-pc-linux-gnu/3.4.6/include
/usr/local/include
/path/to/gcc/include
/usr/include
the expected behavior would be to have the libraries searched before
any of the above are searched. But no, gcc silently ignores this
request, and finds the unwanted version of the include that I want in
/usr/local/include, due to not 'wanting to defeat system headers'.
This I guess I can understand (although it would be very nice to get a
warning). What I can't understand is why /usr/local/include is placed
*above* /path/to/gcc/include in this ordering. Since when is a
directory that has arbitrary installs from userland considered a
necessary part of system headers? Shouldn't the detection order be:
/path/to/gcc/lib/gcc/i686-pc-linux-gnu/3.4.6/include
/path/to/gcc/include
/usr/local/include
/usr/include
if /usr/local/include is to be included at all..
And come to think of it, why *is* the -I ignored? Why doesn't the
preprocessor just trust the user and that they know what they are
doing? Why is -nostdinc even necessary?
Ed