Permanently and reliably set gcc include path globally - c++

Question

System: LMDE4, 64bit, gcc-8.3.0, VS Code
Target File: https://github.com/opencv/opencv/blob/master/samples/cpp/videocapture_camera.cpp
Now as the title says, this starts pissing me off. Nothing is working to fix such a simple issue. And NO I don't want to always use "-I" to tell pretty obvious things to the compiler. Here is what I've done so far.
in c_cpp_properties.json of VS Code:
{
"configurations": [
{
"name": "Linux",
"includePath": [
"${workspaceFolder}/**",
"/usr/include/**"
],
"defines": [],
"compilerPath": "/usr/bin/gcc",
"cStandard": "c11",
"cppStandard": "gnu++14",
"intelliSenseMode": "clang-x64",
"browse": {
"path": [
"/usr/include/"
]
}
}
],
"version": 4
}
in .bashrc:
#C Include
export C_INCLUDE_PATH="/usr/include"
export C_INCLUDE_PATH=$C_INCLUDE_PATH:"/usr/include/opencv2"
#C++ Include
export CPLUS_INCLUDE_PATH="/usr/include"
export CPLUS_INCLUDE_PATH=$CPLUS_INCLUDE_PATH:"/usr/include/c++/8/"
export CPLUS_INCLUDE_PATH=$CPLUS_INCLUDE_PATH:"/usr/include/opencv2"
#C/C++ Include
export CPATH="/usr/include"
I am pretty sure that all the .bashrc exports are already a dirty workaround and still I get the following message on compile:
In file included from /usr/include/c++/8/bits/stl_algo.h:59,
from /usr/include/c++/8/algorithm:62,
from /usr/include/opencv2/core/base.hpp:55,
from /usr/include/opencv2/core.hpp:54,
from ~/LearnDummy/helloworld.cpp:1:
/usr/include/c++/8/cstdlib:75:15: fatal error: stdlib.h: Datei oder Verzeichnis nicht gefunden
#include_next <stdlib.h>
^~~~~~~~~~
compilation terminated.
Well fine... stdlib.h is unknown (Jesus!)... find /usr -name stdlib.h gives me
/usr/include/stdlib.h
/usr/include/c++/8/stdlib.h
/usr/include/c++/8/tr1/stdlib.h
/usr/include/x86_64-linux-gnu/bits/stdlib.h
/usr/include/i386-linux-gnu/bits/stdlib.h
In addition VS Code already knows(!) where the file is once I click on "Go to Definition" and still gcc is blind. How do I get realiably rid of this?

Answer 1

Here is a minimal repro of your problem on Ubuntu 20.04.
$ g++ --version
g++ (Ubuntu 9.3.0-10ubuntu2) 9.3.0
...
$ cat main.cpp
#include <cstdlib>
int main ()
{
return EXIT_SUCCESS;
}
$ export CPLUS_INCLUDE_PATH="/usr/include"; g++ -c main.cpp
In file included from main.cpp:1:
/usr/include/c++/9/cstdlib:75:15: fatal error: stdlib.h: No such file or directory
75 | #include_next <stdlib.h>
| ^~~~~~~~~~
compilation terminated.
Note that export CPLUS_INCLUDE_PATH="/usr/include" here has the same effect as your
identical setting in your .bashrc.
The error does not occur if we remove that environment setting:
$ export CPLUS_INCLUDE_PATH=; g++ -c main.cpp; echo Done
Done
The effect of that environment setting, as per the GCC Manual: 3.21 Environment Variables Affecting GCC
is the same as:
$ g++ -isystem /usr/include -c main.cpp
In file included from main.cpp:1:
/usr/include/c++/9/cstdlib:75:15: fatal error: stdlib.h: No such file or directory
75 | #include_next <stdlib.h>
| ^~~~~~~~~~
compilation terminated.
which accordingly reproduces the error.
The -isystem option is documented in the GCC Manual: 3.16 Options for Directory Search
The general solution to your problem is: Don't run a g++ compilation in any way
that has the effect of g++ ... -isystem /usr/include ...
You can avoid running a g++ command in such a way because the option
-isystem /usr/include is unnecessary. /usr/include is a default search directory
for the preprocessor. You don't need to tell it to look for system header files there -
either via environment settings, or via a VS Code configuration, or any other way.
See the preprocessor's default search order for C++:-
$ echo | g++ -x c++ -E -Wp,-v -
ignoring duplicate directory "/usr/include/x86_64-linux-gnu/c++/9"
ignoring nonexistent directory "/usr/local/include/x86_64-linux-gnu"
ignoring nonexistent directory "/usr/lib/gcc/x86_64-linux-gnu/9/include-fixed"
ignoring nonexistent directory "/usr/lib/gcc/x86_64-linux-gnu/9/../../../../x86_64-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
/usr/include/c++/9
/usr/include/x86_64-linux-gnu/c++/9
/usr/include/c++/9/backward
/usr/lib/gcc/x86_64-linux-gnu/9/include
/usr/local/include
/usr/include/x86_64-linux-gnu
/usr/include ### <- There it is ###
End of search list.
...
So your comment:
I am pretty sure that all the .bashrc exports are already a dirty workaround
is on the money1. But what's worse, the .bashrc setting:
export CPLUS_INCLUDE_PATH="/usr/include"
turns the problem into a persistent feature of your bash profile.
How does the error happen?
The difference that is made to the preprocessor's search order by -isystem /usr/include
can be seen here:
$ echo | g++ -x c++ -isystem /usr/include -E -Wp,-v -
ignoring duplicate directory "/usr/include/x86_64-linux-gnu/c++/9"
ignoring nonexistent directory "/usr/local/include/x86_64-linux-gnu"
ignoring nonexistent directory "/usr/lib/gcc/x86_64-linux-gnu/9/include-fixed"
ignoring nonexistent directory "/usr/lib/gcc/x86_64-linux-gnu/9/../../../../x86_64-linux-gnu/include"
ignoring duplicate directory "/usr/include"
#include "..." search starts here:
#include <...> search starts here:
/usr/include ### <- Was previously last, now is first ###
/usr/include/c++/9
/usr/include/x86_64-linux-gnu/c++/9
/usr/include/c++/9/backward
/usr/lib/gcc/x86_64-linux-gnu/9/include
/usr/local/include
/usr/include/x86_64-linux-gnu
End of search list.
...
As you see, /usr/include is detected now as a duplicated directory in the <...> search
order; the second occurrence - which was last, previously - is deleted and the first occurrence is
retained, coming first in the search order.
Now recall the diagnostic:
/usr/include/c++/9/cstdlib:75:15: fatal error: stdlib.h: No such file or directory
75 | #include_next <stdlib.h>
| ^~~~~~~~~~
The preprocessor directive #include_next is not a standard directive, it is
a GCC extension, documented in the GCC manual: 2.7 Wrapper Headers
Whereas #include <stdlib.h> means:
Include the first file called stdlib.h discovered in the <...> search order, starting from the start
#include_next <stdlib.h> means:
Include the next file called stdlib.h discovered in the <...> search order, starting from the
directory right after that of the file being processed now.
The only directory in the <...> search order that contains stdlib.h is /usr/include. So,
if #include_next <stdlib.h> is encountered by the preprocessor in any file in any directory dir in the <...>
search order, while /usr/include is first in the <...> search order, there can be no directory
later than dir in the <...> search order where <stdlib.h> will be found. And so the error.
#include_next <foobar.h> can only work if the <...> search order places the directory containing
<foobar.h> after the one that contains the file that contains the directive. As a rule of thumb,
just don't mess with the <...> search order.
The problem just discussed was the subject of a regression bug-report raised against GCC 6.0.
As you can see there, the resolution was WONTFIX.
[1] All of your .bashrc exports as posted are, as you suspect, poor practice.
It isn't necessary to tell the preprocessor about any search directories in
its default search order. You can only make things wrong.
Directories that will not be found by default should be specified by
-I dir options specified on the commandline (typically injected via parameters
of the build configuration), so that these non-default options are visible in build logs
for trouble shooting. "Invisible hands" are to be avoided in build systems to the
utmost practical extent.