3

Both gcc and clang seem to silently discard /usr/include from the list of include directories when explicitly included via -I. Is there a specific reason as to why common compilers apparently don't allow to include the system's include dir?


background:

Suppose you depend on a header file located in /usr/include while having inherited a directory containing an incompatible version of the same header from your build system via the CPATH environment variable (effectively appending that directory to the -I list from the right).

1
  • 1
    Create a new directory, symlink the files you want there, and point -I at that new directory. This avoids side effects that you do not control. Commented Nov 22, 2018 at 21:36

1 Answer 1

2

GCC ignores -I/usr/include because it is a system header directory by default, and using -I would turn it into non-system header, leading to confusing behavior, particularly with system headers that are not entirely aligned with language standards. (GCC gives system headers more latitude and suppresses warnings, for example.)

If you use -isystem /usr/include, then /usr/include moves to the front of the search list. However, you will likely have to move the other default search path entries as well, to avoid breaking too many things. gcc -v will print the entire search path.

Sign up to request clarification or add additional context in comments.

4 Comments

But please don't use -isystem /usr/include. The system headers are searched in a very specific order, and changing that order will break things.
Good point, it will likely be necessary to move the other default search paths as well.
-isystem wouldn't be able to override CPATH anyway since it has lower precedence than CPATH (which effectively is equivalent to -I).
-nostdinc could help, though that's going to be a fragile hack.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.