Boston Linux & Unix (BLU) Home | Calendar | Mail Lists | List Archives | Desktop SIG | Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings
Linux Cafe | Meeting Notes | Blog | Linux Links | Bling | About BLU

BLU Discuss list archive


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Discuss] really odd GCC bug? under Ubuntu



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



BLU is a member of BostonUserGroups
BLU is a member of BostonUserGroups
We also thank MIT for the use of their facilities.

Valid HTML 4.01! Valid CSS!



Boston Linux & Unix / webmaster@blu.org