Not gcc but actually cpp. It is convenient to think of the compiler as one huge, monolithic program but this is not the case. And the preprocessor - cpp - is the first one in the chain that devours source code and digests it to executable code.

You can actually bring cpp to show you the default location(s) it would look at for header files by issuing cpp -v. The relevant part of the output would look similar to (the redirection is necessary, otherwise it waits for input):

Code:

$ cpp -v < /dev/null
[...]
#include "..." search starts here:
#include <...> search starts here:
 /usr/lib/gcc/x86_64-linux-gnu/7/include
 /usr/local/include
 /usr/lib/gcc/x86_64-linux-gnu/7/include-fixed
 /usr/include/x86_64-linux-gnu
 /usr/include
End of search list.
[...]

Apart from"see above", this is "more or less correct but not quite". ;-)) In fact the preprocessor doesn't look in the current directory but the one where the source file is located. If you compile a source file in the current directory (which is mostly the case) this makes no difference but if you do:

Code:

user@host:/my/current/directory> gcc -c /some/where/myprogram.c

and in the source there is the line #include "myprogram.h" then cpp would look in /some/where/ for myprogram.h and not your current directory /my/current/directory. I suppose this makes a lot more sense than if it would be the other way round.

Regarding your question about the location of CFLAGS: be aware that the construction of the commandline is done simply by text replacement. Where the name of a variable (like $(CFLAGS)) stands it is replaced by the content of that variable. The called program will only "see" the result of these replacements, so ask yourself: would the resulting compiler call be syntactically correct or not?

I hope this helps.

bakunin