This is a problem that I ran into several times and also colleagues have run into every now and then. Something changed and all of the sudden a built-from-source clang bails out from compilation with an error that it can’t find <cstddef> anymore (or some other standard include header). But when and why does that happen and how can one fix that? Let’s see.

To me this typically happened after some new packages got installed or updated. To a colleague it happened after a dist-upgrade on his Ubuntu workstation (or server or whatever). Long story short: The reason boils down to that some package brought-in a newer GCC version or standard C++ runtime version. At least it brought-in parts of it. This confuses the logic inside the clang driver code that determines which GCC toolchain to use when searching for the standard includes — and we end up with the error.

When this error happens, I typically determine the GCC version of my regular GCC compiler on that system. I then use the -v option to output the verbose log of what clang does under its driver cover. This reveals the search paths it uses for standard includes. You should look out for GCC versions that are newer (i.e., bigger number) than what you got from the version command of your GCC installation. If we find a newer search path then we can install the according library headers that are needed via the *-dev package (and the rest of the compiler potentially) or find out why these compiler components were installed and potentially remove them again.

# 1. Determine the GCC version
$> gcc --version
# 2. Set clang to verbose mode to reveal search paths for system includes
clang++ -v < whatever is offending compile command >
# 3. Inspect search paths for newer versions than seen in 1.
# 4. Assuming debian-based distro, determine installed libraries
$> apt list -i | grep libstdc++
# 5. (optional) install whatever newer libstdc++-dev needs to be installed
$> sudo apt install libstdc++-<VERSION>-dev

Once these additional libraries are installed, or the offending include versions are removed, clang should again work as expected and everything should be great. If that is not the case, the reason is something different and this little post was not helpful to resolve your problem. But maybe you learned something and still enjoyed reading through it.

The reason for this behavior is that clang tries to identify which includes should likely be used and as “a heuristic”, it simply uses the newest available version. I think the source code lists this as a TODO, at least they used to back in clang-3.7 days. However, it is a surprisingly hard and annoying problem to solve.

No responses yet

Leave a Reply

Your email address will not be published. Required fields are marked *