-I dir vs. -isystem dir - c

If I want to include directories to be searched for header files, which is the preferred way and why?

One way to view this is to use headers that you control with -I and the ones you don't (system, 3rd party libs) with -isystem. The practical difference comes when warnings are enabled in that warnings which come from -isystem headers will be suppressed.

From the gcc documentation for -I:
Add the directory dir to the head of the list of directories to be searched for header files. This can be used to override a system header file, substituting your own version, since these directories are searched before the system header file directories. However, you should not use this option to add directories that contain vendor-supplied system header files (use -isystem for that). If you use more than one -I option, the directories are scanned in left-to-right order; the standard system directories come after.
If a standard system include directory, or a directory specified with -isystem, is also specified with -I, the -I option will be ignored. The directory will still be searched but as a system directory at its normal position in the system include chain. This is to ensure that GCC's procedure to fix buggy system headers and the ordering for the include_next directive are not inadvertently changed. If you really need to change the search order for system directories, use the -nostdinc and/or -isystem options.
So -I is probably the preferred option to specify the location of your header files, except for special cases such as vendor-supplied system headers.

You should use -I to specify the location of your headers.
The files you specify with -isystem are searched after -I is processed and receive a special treatment by gcc (the same as standard system headers).

So here's the difference I've found by running some experiments. Imagine the following setup:
my_std_lib/stdio.h
#ifndef _CUSTOM_STDIO_H
void test() {}
#endif
#include_next <stdio.h>
#include_next <custom.h>
my_user_lib/custom.h
#ifndef _CUSTOM_HEADER_H
void custom_func() {}
#endif
main.cpp
#include "stdio.h"
int main() {
test();
custom_func();
printf("Hello world!");
return 0;
}
If you compile using
g++ -isystem my_std_lib -isystem my_user_lib main.cpp everything will work fine.
However, g++ -isystem my_std_lib -I my_user_lib main.cpp will result into an error
In file included from main.cpp:1:
my_std_lib/stdio.h:10:15: fatal error: 'custom.h' file not found
#include_next <custom.h>
^~~~~~~~~~
1 error generated.
So what is going on?
To my understanding, when I write #include "stdio.h", GCC will start traversing the list of available header files until it finds my_std_lib/stdio.h. Directive #include_next <custom.h> at the end of this file tells the compiler to search for a custom.h by traversing include directories from its current position onwards.
When I add my_user_lib to the list of directories using -I flag, it appears before all the system directories in the directory list. Therefore, it appears in the list before my_std_lib directory and the #include_next fails.
The same would happen if I were to compile using g++ -isystem my_user_lib -isystem my_std_lib main.cpp. Apparently, directories are added to the list in the same order the flags are specified, so, again, my_user_lib will come before my_std_lib.
So in a nutshell, -I and -isystem differ in a way they add their target to the list of include directories.

When you include a header "Myheader.h" using -I, the compiler generates search order: "Myheader.h" , "system/headers". So if something can't be found in "MyHeader.h" you fallback on "system/headers". However when you use -isystem, you are basically saying that replace "system/headers" with whatever I give you. So there is no more falling back on "system/headers".

Related

Does `#include "FILE.h"` make gcc search for FILE.h in the current directory or somewhere else?

An Introduction to GCC by Brian Gough says
Incidentally, the difference between the two forms of the include state-
ment #include "FILE.h" and #include <FILE.h> is that the former
searches for FILE.h in the current directory before looking in the system header file directories. The include statement #include <FILE.h>
searches the system header files, but does not look in the current directory by default.
But the following example seems to imply the directory containing the source file being compiled, instead of the current directory. What is correct?
$ mv src/hello.h .
$ gcc -c src/main.c
src/main.c:1:10: fatal error: hello.h: No such file or directory
#include "hello.h"
^~~~~~~~~
compilation terminated.
$ mv hello.h src/
$ gcc -c src/main.c
$
https://gcc.gnu.org/onlinedocs/cpp/Search-Path.html states that
By default, the preprocessor looks for header files included by the quote form of the directive #include "file" first relative to the directory of the current file, and then in a preconfigured list of standard system directories. For example, if /usr/include/sys/stat.h contains #include "types.h", GCC looks for types.h first in /usr/include/sys, then in its usual search path.
For the angle-bracket form #include <file>, the preprocessor’s default behavior is to look only in the standard system directories.
The document you are reading is therefore incorrect. Perhaps Mr. Gough has never attempted to write a nonrecursive Makefile, or separate his source and object directories, and has therefore never noticed that "the current directory" and "the directory containing the current file" are not necessarily the same thing.
GCC has a whole bunch of command line options that you can use to reconfigure how #include works. There is even an option that turns off looking in the directory of the current file (-I-), but it is not usable on many operating systems because it will break the C library's headers.

Disable certain warnings for system headers

I'm usually compiling my projects with -Werror and some warnings turned on (like -Wsequence-point -Wcast-align -Wstrict-prototypes -Wstrict-aliasing).
With these settings, on some platforms some headers produce warnings when included (which turn into errors because of the first switch). For example I've seen this with some X11 headers on MacOS.
I don't want to degrade the quality standards for my code. Is there a way to make my project compile without disabling problematic warnings globally? For example is there a way to disable warnings only for included headers out of my project?
EDIT
Here is an example of the problem I'm trying to solve:
gcc -std=c99 -pthread -O2 -fstrict-aliasing -I/usr/X11/include -Werror -Wpedantic -Wstrict-aliasing -Wchar-subscripts -Wimplicit -Wsequence-point -Wwrite-strings -Wunused-variable -Wvla -c -o main.o main.c
/usr/X11/include/X11/Xfuncproto.h:145:24: error: named variadic macros are a GNU extension [-Werror,-Wvariadic-macros]
#define _X_NONNULL(args...) __attribute__((nonnull(args)))
The GCC manual on Options for Directory Search lists:
These options specify directories to search for header files, for libraries and for parts of the compiler:
-I dir
-iquote dir
-isystem dir
-idirafter dir
Add the directory dir to the list of directories to be searched for header files during preprocessing. If dir begins with ‘=’, then the ‘=’ is replaced by the sysroot prefix; see --sysroot and -isysroot.
Directories specified with -iquote apply only to the quote form of the directive, #include "file". Directories specified with -I, -isystem, or -idirafter apply to lookup for both the #include "file" and #include <file> directives.
You can specify any number or combination of these options on the command line to search for header files in several directories. The lookup order is as follows:
For the quote form of the include directive, the directory of the current file is searched first.
For the quote form of the include directive, the directories specified by -iquote options are searched in left-to-right order, as they appear on the command line.
Directories specified with -I options are scanned in left-to-right order.
Directories specified with -isystem options are scanned in left-to-right order.
Standard system directories are scanned.
Directories specified with -idirafter options are scanned in left-to-right order.
You can use -I to override a system header file, substituting your own version, since these directories are searched before the standard system header file directories. However, you should not use this option to add directories that contain vendor-supplied system header files; use -isystem for that.
The -isystem and -idirafter options also mark the directory as a system directory, so that it gets the same special treatment that is applied to the standard system directories.
If a standard system include directory, or a directory specified with -isystem, is also specified with -I, the -I option is ignored. The directory is still searched but as a system directory at its normal position in the system include chain. This is to ensure that GCC’s procedure to fix buggy system headers and the ordering for the #include_next directive are not inadvertently changed. If you really need to change the search order for system directories, use the -nostdinc and/or -isystem options.
The second last paragraph quoted notes that designating directories with -isystem suppresses the warnings as they are suppressed for any other system header (by default).
The Options to Request or Suppress Warnings section of the manual includes:
-Wsystem-headers
Print warning messages for constructs found in system header files. Warnings from system headers are normally suppressed, on the assumption that they usually do not indicate real problems and would only make the compiler output harder to read. Using this command-line option tells GCC to emit warnings from system headers as if they occurred in user code. However, note that using -Wall in conjunction with this option does not warn about unknown pragmas in system headers—for that, -Wunknown-pragmas must also be used.
So, by designating the directory that contains the /usr/X11/include/X11/Xfuncproto.h file as a system directory with:
-isystem /usr/X11/include
you should not get warnings from #include <X11/Xfuncproto.h> any more.

Check what files is 'make' including

I'm compiling a kernel module and I'm including <asm/unistd.h>, but I'm not sure if the compiler is using the unistd.h from /usr/includes/ (wrong) or the one from /usr/src/kernel-3.x.x/arch/x86/includes/ (right).
My question is: How can I check which one of those two is the compiler using?
And also, is there a way to force the file from the kernel headers instead of the one from /usr/include?
cpp code.c | grep unistd.h
or
gcc -E code.c | grep unistd.h
To answer the second part of your question:
And also, is there a way to force the file from the kernel headers instead of the one from /usr/include?
You can pass the -nostdinc option to gcc:
"Do not search the standard system directories for header files. Only the directories you have specified with -I options (and the directory of the current file, if appropriate) are searched."
GCC: Options Controlling the Preprocessor

How To Include Files From Multiple Directories In C on Linux?

gcc main.c -o main -I include
I am creating a small c application with following directory structure:
app=>
=>src (a directory, with all source files)
=>include (a directory, with all header files)
=>common (a directory, with all common files)
=>main.c
Now I am trying to run main.c which contains #include directive to include header files from include directory and function calls to .c files in both common and src directories. I am using -I option but it is useful only for one directory path indication.
How does the compiler will look in all src, common and include directories to resolve the calls.
Kindly suggest me a command or make file to provide path of multiple directories while compiling with gcc.
Multiple -I options are permitted. The description of the -I option from Options for Directory Search
states:
Add the directory dir to the head of the list of directories to be searched for header files. This can be used to override a system header file, substituting your own version, since these directories are searched before the system header file directories. However, you should not use this option to add directories that contain vendor-supplied system header files (use -isystem for that). If you use more than one -I option, the directories are scanned in left-to-right order; the standard system directories come after.
For example:
gcc main.c -o main -Iinclude -Isrc/include -Icommon/include
Note that if main.c is using functions implemented in another .c file(s) then the other .c files will also need compiled and linked into the final program binary. For example:
gcc main.c src/another.c -o main -Iinclude -Isrc/include -Icommon/include

Manipulating the search path for include files

My development environment is such that I have some_header.h in /usr/include and in /another/directory. /another/directory contains some header files I need to include in my program, but I want to use some_header.h from /usr/include. When I use
gcc ... -I/another/directory
gcc uses /another/directory/some_header.h. If I use
gcc ... -I/usr/include -I/another/directory
gcc does the same thing because it ignores /usr/include since it is part of the standard search path, but it gets searched after non standard directories included with -I.
Any ideas?
Use the -iquote switch:
Include the files that are in another/directory using quotes:
#include "another_file.h"
Then use
gcc -iquote /another/include ...
to add a search path for quoted include files. This switch will add a directory that is searched for quoted include files after the current directory and before -I and system include paths.
Include your other include files using brackets (i.e. #include <header.h>).
See here for more information:
Where are include files stored - Ubuntu Linux, GCC
Have you looked at -nostdinc ?
The manual says:
-nostdinc
Do not search the standard system directories for header files.
Only the directories you have specified with -I options (and the
directory of the current file, if appropriate) are searched.
Of course that means that you will have to specify anything that normally goes on the standard search path that you do want...
Have you tried unsetting the system INCLUDE path environment variable?

Resources