Build fails on Arch Linux

[mayjs]

The build of cppinsights fails on Arch Linux.
The error message is:

In file included from /usr/include/c++/8.3.0/ext/string_conversions.h:41,
                 from /usr/include/c++/8.3.0/bits/basic_string.h:6400,
                 from /usr/include/c++/8.3.0/string:52,
                 from /usr/include/c++/8.3.0/stdexcept:39,
                 from /usr/include/c++/8.3.0/array:39,
                 from /usr/include/c++/8.3.0/tuple:39,
                 from /usr/include/c++/8.3.0/bits/unique_ptr.h:37,
                 from /usr/include/c++/8.3.0/memory:80,
                 from /usr/include/llvm/Support/Casting.h:21,
                 from /usr/include/clang/Basic/LLVM.h:22,
                 from /usr/include/clang/AST/APValue.h:17,
                 from /usr/include/clang/AST/Decl.h:17,
                 from /usr/include/clang/AST/ASTTypeTraits.h:20,
                 from /usr/include/clang/AST/ASTContext.h:19,
                 from /usr/include/clang/AST/AST.h:18,
                 from ../Insights.cpp:8:
/usr/include/c++/8.3.0/cstdlib:75:15: fatal error: stdlib.h: No such file or directory

I've looked around a bit and found that this is somehow related to the -isystem/usr/include arguments that is used in the generated build.ninja file. Replacing all the -isystem parts with -I fixed the issue for me: sed -i "s/-isystem/-I/g" build.ninja, but this should be fixed in the CMake files somehow I think.

[andreasfertig]

Hello @mayjs,

interesting and thanks for tracing it so far. Can you give more details about the build environment. Was it a out-of-clang build? What did CMake initially print out?

Andreas

[bstaletic]

This is a problem with include path ordering. The order is:

1. -isystem paths
2. Implicit system include paths
3. -I paths

This combined with the fact that /usr/include absolutely has to be the last of the system include paths can cause problems. What happens here is that specifying only -isystem/usr/include makes /usr/include come before all other implicit system include paths.

[bstaletic]

A few more bits of information:

• Include paths can be examined with clang++ -E -v.

• The reason why the order matters is in the line right after what @mayjs posted:

  #include_next <stdlib.h>

With include paths reordered, #include_next from cstdlib is unable to find anything in /usr/include.

[andreasfertig]

I do tamper a bit with the includes in CMakeLists.txt.

I'm not sure what a better solution might be.

[bstaletic]

That line turns user defined include paths (-I) into system include paths (-isystem) which should be fine unless someone explicitly declared the implicit include paths as -I. And even then you'd be fine if all implicit paths got "transformed" (for lack of a better word). The problem would appear if only some of implicit include paths got turned explicit with -isystem.

[stale]

Thanks for contributing to this issue. As it has been 60 days since the last activity waiting for a followup. This issue will be automatically closed in 7 days, if no further activity occurs. This is often because the request was already solved in some way and it just wasn't updated or it's no longer applicable. If that's not the case, please respond before the issue is closed. We'll gladly take a look again! In any case, thank you for your contributions!