Discussion:
What are GCC's "Standard system directories" on GNU/Linux?
Add Reply
Alan Mackenzie
2025-02-05 11:38:44 UTC
Reply
Permalink
Hello, comp.lang.c.

In the GCC manual, section 3.16 "Options for Directory Search" partially
describes where, how, and in what order GCC finds #include files when
compiling.

It's the "partially" bit which is getting on my nerves. The manual
section contains a priority list for finding #include files, but the
fifth item just vaguely states:

5. Standard system directories are scanned.

. Which directories are these? Where is this documented?

I'm not stupid, I know vaguely what the purpose of these directories is.
But I need to know precisely which directories they are.

GCC was built mainly for the GNU project. Why must the manual be so
vague on this point, even for GNU/Linux?
--
Alan Mackenzie (Nuremberg, Germany).
Dan Purgert
2025-02-05 13:05:57 UTC
Reply
Permalink
Post by Alan Mackenzie
Hello, comp.lang.c.
In the GCC manual, section 3.16 "Options for Directory Search" partially
describes where, how, and in what order GCC finds #include files when
compiling.
It's the "partially" bit which is getting on my nerves. The manual
section contains a priority list for finding #include files, but the
5. Standard system directories are scanned.
. Which directories are these? Where is this documented?
It is, as I recall, defined at compile time of gcc. You can get your
system-specific "standard system directories" by running the command:

echo | gcc -xc -E -v -

It'll print out a bunch of stuff, starting off with the compile-time
options that were used when compiling gcc itself. The bit you're
looking for being listed out under the heading:

#include <...> search starts here:


HTH
--
|_|O|_|
|_|_|O| Github: https://github.com/dpurgert
|O|O|O| PGP: DDAB 23FB 19FA 7D85 1CC1 E067 6D65 70E5 4CE7 2860
Alan Mackenzie
2025-02-05 13:58:33 UTC
Reply
Permalink
Hello, Dan.
Post by Dan Purgert
Post by Alan Mackenzie
In the GCC manual, section 3.16 "Options for Directory Search" partially
describes where, how, and in what order GCC finds #include files when
compiling.
It's the "partially" bit which is getting on my nerves. The manual
section contains a priority list for finding #include files, but the
5. Standard system directories are scanned.
. Which directories are these? Where is this documented?
It is, as I recall, defined at compile time of gcc. You can get your
echo | gcc -xc -E -v -
It'll print out a bunch of stuff, starting off with the compile-time
options that were used when compiling gcc itself. The bit you're
HTH
Thank you indeed! That was extremely helpful, and told me everything I
need to know.

I'm creating my own version of the linux kernel, and have several
application programs to build that must #include files from this version
rather than the standard ones.

The listing from the command you gave me tells me that <linux/kd.h> will
be read from /usr/include/linux/kd.h, and so on. Now I know that, I can
amend the Makefiles.
Post by Dan Purgert
--
|_|O|_|
|_|_|O| Github: https://github.com/dpurgert
|O|O|O| PGP: DDAB 23FB 19FA 7D85 1CC1 E067 6D65 70E5 4CE7 2860
--
Alan Mackenzie (Nuremberg, Germany).
Kaz Kylheku
2025-02-05 18:46:22 UTC
Reply
Permalink
Post by Alan Mackenzie
Hello, comp.lang.c.
In the GCC manual, section 3.16 "Options for Directory Search" partially
describes where, how, and in what order GCC finds #include files when
compiling.
It's the "partially" bit which is getting on my nerves. The manual
section contains a priority list for finding #include files, but the
5. Standard system directories are scanned.
. Which directories are these? Where is this documented?
All that stuff depends on the GCC installation, and therefore cannot
be specified in concrete terms in a general document.

Unfortunately

gcc -print-search-dirs

does not have info about the include file search directories. I'm guessing that
could have to do with the split between the compiler and preprocessor.

Anyway, we can coax the information out of the preprocessing stuff,
by adding the -v option to gcc -E.

Try this:

$ echo | gcc -xc -E -v - 2>&1 | awk '/include.*search starts here/,/End of search list/'
#include "..." search starts here:
#include <...> search starts here:
/usr/lib/gcc/i686-linux-gnu/7/include
/usr/local/include
/usr/lib/gcc/i686-linux-gnu/7/include-fixed
/usr/include/i386-linux-gnu
/usr/include
End of search list.

The above happens to come from a 32 bit Ubuntu 18 VM, that I maintain for
compiling for 32 bit Intel. (You cannot install that from scratch; 32 bit
support started to be deprecated after Ubuntu 16; I created that VM by
upgrading from 16.)
--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @***@mstdn.ca
Michael S
2025-02-05 22:08:23 UTC
Reply
Permalink
On Wed, 5 Feb 2025 18:46:22 -0000 (UTC)
Post by Kaz Kylheku
Post by Alan Mackenzie
Hello, comp.lang.c.
In the GCC manual, section 3.16 "Options for Directory Search"
partially describes where, how, and in what order GCC finds
#include files when compiling.
It's the "partially" bit which is getting on my nerves. The manual
section contains a priority list for finding #include files, but the
5. Standard system directories are scanned.
. Which directories are these? Where is this documented?
All that stuff depends on the GCC installation, and therefore cannot
be specified in concrete terms in a general document.
Unfortunately
gcc -print-search-dirs
does not have info about the include file search directories. I'm
guessing that could have to do with the split between the compiler
and preprocessor.
Anyway, we can coax the information out of the preprocessing stuff,
by adding the -v option to gcc -E.
I find -M easier.
Post by Kaz Kylheku
$ echo | gcc -xc -E -v - 2>&1 | awk '/include.*search starts
/usr/lib/gcc/i686-linux-gnu/7/include
/usr/local/include
/usr/lib/gcc/i686-linux-gnu/7/include-fixed
/usr/include/i386-linux-gnu
/usr/include
End of search list.
The above happens to come from a 32 bit Ubuntu 18 VM, that I maintain
for compiling for 32 bit Intel. (You cannot install that from
scratch; 32 bit support started to be deprecated after Ubuntu 16; I
created that VM by upgrading from 16.)
Loading...