Where "standard system include directory" is defined? (gcc)
 

Hi, Penguins.

BIG APOLOGIES for pre beginner question.

This penguin got totally confused.:study:

With gcc (linux), "man gcc" says -I/search/directory/ "Add the directory dir to the list of directories to be searched for header files. Directories named by -I are searched before the standard system include directories. If the directory dir is a standard system include directory, ....."

http://gcc.gnu.org/onlinedocs/gcc/Di...y-Options.html says similar thing and several environment variables.

Then, confusion comes, "which directory is standard system include directory" where is definition?
I am very sure (although not 100%) /usr/include is one of them.

Where can I find definition of "standard system include directory(is)?

HUGE APOLOGIES again :Pengy:

Hi -

You're 100% correct - "/usr/include" is the standard "system directory" under Unix and Linux.

"/usr/local/include" is another Pop Favorite.

Under Windows, Visual Studio sets environment variables like %INCLUDE%, %LIB% and %MSVCDir%.

As you saw in the link you quoted, GCC also allows you to set environment variables, like $CPATH, $C_INCLUDE_PATH and $CPLUS_INCLUDE_PATH:
http://gcc.gnu.org/onlinedocs/gcc/En...ment-Variables

Thanks for prompt reply.

This question came from "is /usr/local/include" standard system include directory?

I do not know anything about evil bill's junk. Old Macintosh used to use #include <this.h> for whatever found InsideMac (Apple defined), #include "that.h" for user defined ones.... Pascal was the official language, C was a dialect.

(Note that this is all based on GCC 3.3.3 and GCC 3.4.4 because those are the only versions I have installed. The -isystem option is not documented in my GCC 3.4.4 manpage but it still works. As far as GCC > 3.4 goes you're on your own I'm afraid.)

With various options (such as -I and -I- and -isystem) you can specify lots of different inclusion features. Basically, directories specified by -I will be searched before those specified by -isystem, which will in turn be searched before those in the "standard system include directories" (at least, according to my tests). The difference is that -I can be used for any #include directive, but -isystem will only be used for #include <...> That said, though, it is recommended to only use -I for #include "..." directives because of the search order. Using -I- really gives you a lot of control because any -I used before -I- will be searched for only for #include "..." whilst any -I used after -I- will be searched for any #include directive. In addition, using -I- means that the current directory will not be searched for included files unless you also specify -I. (search the current directory).

If you want to get a listing of what search directories are supported by default, try running this command: `cpp -v < /dev/null` This runs the GNU C Preprocessor with no input; in the process it will print (given the -v flag) the inclusion directory search paths. You should see phrases like "#include <...> search starts here:" followed by a list of directories. Those are your standard inclusion search paths, in the order that they're searched.

In most cases, you will specify which inclusion directories you want searched with the appropriate options to GCC from a Makefile or the like. If you specify a directory that's already given, there's no problem because it will simply be ignored. So almost 100% of the time it's not really necessary to know what the default search directories are. Aside from running cpp with no input, like I say above, I don't know that there's any way to tell what the defaults are. Also, I don't know when they're specified - probably at compile time, but I don't know where or how. Hope this helps you somewhat.

Oh, and you are absolutely correct about the difference between #include "..." and #include <...> Although, since it's only a matter of how directories specified as arguments to the preprocessor are searched, I think it's really more style and form than anything technical. That said, we should all probably continue to stick to the convention of separating code we wrote specifically for the given project from general system inclusion files that anybody might use for anything.

Thanks a lot.

Yes, your explanation helped a little bit more than somewhat.

I am working on tarball which chokes while compile. To make things worse, I have almost zero experience with inside "make" and "configure", althugh I used many times.

Now, I know how I can find which include file went through default path, and which went through -I or whatever.

Actually, I checked ANSI book and found that #include <your_code> searches your_code in system (system dependent manner) and that #include "my_code" looks for my_code in my directory (system dependent manner). So, it is ANSI standard.

Hi, again -

1. More informally:
2. As far as your original question, "/usr/include" and "/usr/local/include" are the two "system header paths" where you DON'T usually need to specify a "-I..." include path.

You can modify the "system header path" with compiler-dependent variables like $C_INCLUDE_PATH and $CPLUS_INCLUDE_PATH.

3. Feel free to post specific compile errors and ask how you might fix them. It might be best to create a new thread each time you ask a new, different question.

Be sure to cut/paste the specific error message, and be sure to put them in "[quote]" or in "[code]" blocks.

'Hope that helps .. PSM

Thank you for your additional information.

However, I need to know either yes/no answer if /usr/local/include is "standard system include directory" on my penguin (gcc404). More specific, at some spot during "make all" process (10min+ output is long).

So far,
1. -I/search/this/directory does not affect "standard system include directory".
2. My penguin does not have any shell environment, which affect include path. (I still do not know if "standard ..... directory" is altered by these environment.)
3. thus, I assume whatever directories "cpp -v < /dev/null" returns are "standard ... directories at shell prompt.
4. 3. is also true during make process. (no setenv, export during the process.)
5. I also need to figure out what "special treatment of system headers" is. (found in "man gcc")

I think "special treatment of system headers" means that they are immune to some warnings.
http://gcc.gnu.org/onlinedocs/gcc-3....stem%20Headers

Am I correct?

related thread
 

This thread came up recently, I think it may give you some more information, even though it does sort of contradict the result of the `cpp -v < /dev/null` thing: http://www.linuxquestions.org/questi...d.php?t=466499