![]() |
Home
| Calendar
| Mail Lists
| List Archives
| Desktop SIG
| Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings Linux Cafe | Meeting Notes | Linux Links | Bling | About BLU |
On Sat, May 11, 2013 at 3:12 PM, Jason Merrill <jason.merrill at gmail.com> wrote: > This is the expected behavior. From > http://gcc.gnu.org/onlinedocs/cpp/Search-Path.html : > > GCC looks in several different places for headers. On a normal Unix system, > if you do not instruct it otherwise, it will look for headers requested with > #include <file> in: > > /usr/local/include > libdir/gcc/target/version/include > /usr/target/include > /usr/include On reflection, I'm only mildly surprised that GCC looks in /usr/local include by default. Given GCC's original development as a replacement C compiler having it look for include files somewhere else then /usr/include by default makes sense. However, I am more surprised that GCC will happily ignore the fact that those directories don't exist; but will fail with a fatal error if they exist, but are not accessible to the compiler. It appears that this is true on a per file basis as well. If I put an unreadable file called foo.h in /usr/local/include and do a #include <foo.h> in my source, I get a permission denied error even if /usr/include/foo.h exists and is world readable. I (naively) expected the preprocessor to try all of the directories before giving up. In any case, thanks for the explanation. Bill Bogstad