This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]