llvm
'__config_site' file not found on Ubuntu noble for libc++-18
For about a week now, libc++-18 does not provide the /usr/include/c++/v1/__config_site header file.
Installed with:
sudo apt install libc++-18-dev libc++abi-18-dev
libc++-19 is OK.
Compilation error log:
In file included from /usr/bin/../include/c++/v1/exception:79:
In file included from /usr/bin/../include/c++/v1/__assert:13:
In file included from /usr/bin/../include/c++/v1/__assertion_handler:13:
/usr/bin/../include/c++/v1/__config:13:10: fatal error: '__config_site' file not found
More info can be found here: https://github.com/mpusz/mp-units/actions/runs/9597865534/job/26467862493.
I don't think this is a libc++ issue, we didn't change anything on our side. This seems like a packaging issue to me.
@mpusz Are you able to find __config_site anywhere in your include tree?
@petrhosek, didn't we introduce some changes around the libcxx multilib build to address this? I have a vague recollection that this cropped up for us about a month ago, but I don't recall the full story.
I encountered the same problem on my virtual machine.
os : 20.04.1-Ubuntu
you can find the __config_site here (Replace your installation path):
@mpusz reports that the file isn't anywhere in his include tree, which would point to a different issue though. It looks like a packaging issue to me, not a libc++ issue.
Yes, there is __config_site in /usr/lib/llvm-18/include/x86_64-pc-linux-gnu/c++/v1 but this is not the directory linked during installation:
/usr/include/c++$ ls -al
total 96
drwxr-xr-x 8 root root 4096 Jun 21 17:38 .
drwxr-xr-x 75 root root 20480 Jun 21 17:38 ..
drwxr-xr-x 12 root root 4096 May 27 11:30 14
lrwxrwxrwx 1 root root 32 Jun 15 09:01 v1 -> ../../lib/llvm-18/include/c++/v1
There is no __config_site file in /usr/include/c++/v1.
Same issue: Ubuntu LLVM version 18.1.8.
Package is llvm-toolchain-jammy-18
Do we have any update on this issue? CI runs fail because of it for two weeks now 😢
For example: https://github.com/mpusz/mp-units/actions/runs/9732819135
@petrhosek, didn't we introduce some changes around the libcxx multilib build to address this? I have a vague recollection that this cropped up for us about a month ago, but I don't recall the full story.
No, those changes were related to multilib build which is not the issue here. I'm not aware of any related recent changes, and I agree with @ldionne, this looks like a packaging issue.
@mpusz I think the symlink is not the problem here. It is expected that /usr/include/c++/v1 is a symlink to /usr/lib/llvm-18/include/c++/v1, not to the triple-dependent path.
However, I don't understand why Clang isn't also adding a search path for /usr/lib/llvm-18/include/x86_64-pc-linux-gnu/c++/v1 where it would find __config_site. Can you do another run of e.g. https://github.com/mpusz/mp-units/actions/runs/9732819135/job/26932057037 where you also add -v to the compiler invocation? That will print the header search paths it is looking at.
FWIW, I tried reproducing with:
# Dockerfile
FROM ubuntu:latest
RUN <<EOF
apt-get update || true
apt-get install -y sudo || true
echo "ALL ALL = (ALL) NOPASSWD: ALL" | tee /etc/sudoers || true
EOF
RUN apt-get install -y lsb-release wget software-properties-common gnupg
RUN wget https://apt.llvm.org/llvm.sh
RUN chmod +x llvm.sh
RUN sudo ./llvm.sh 18
RUN sudo apt install -y clang-tools-18
RUN sudo apt install -y libc++-18-dev libc++abi-18-dev libunwind-18-dev
I build that Docker image, I then do docker run -it <SHA OF THE IMAGE> and from within the container I do:
echo "#include <string>" | clang++-18 -xc++ - -std=c++17 -stdlib=libc++ -v
This results in the right paths being searched and I am not seeing any problem. There's probably something wrong with this reproducer, however if you're able to tweak your build configuration to reproduce it simply like the above, that would also be helpful for us to investigate.
@ldionne Thanks for investigating it.
I just added -v on my local PC:
[build] [1/79] Scanning /home/mpusz/repos/mp-units/test/static/angular_test.cpp for CXX dependencies
[build] FAILED: test/static/CMakeFiles/unit_tests_static.dir/Release/angular_test.cpp.o.ddi
[build] "/usr/bin/clang-scan-deps-18" -format=p1689 -- /usr/bin/clang++-18 -DMP_UNITS_API_CONTRACTS=3 -DMP_UNITS_API_NO_CRTP=1 -DMP_UNITS_API_STD_FORMAT=1 -DMP_UNITS_API_STRING_VIEW_RET=1 -DMP_UNITS_HOSTED=1 -DCMAKE_INTDIR=\"Release\" -I/home/mpusz/repos/mp-units/src/core/include -I/home/mpusz/repos/mp-units/src/systems/include -isystem /home/mpusz/.conan2/p/ms-gs972aa6e83ce46/p/include -m64 -stdlib=libc++ -v -O3 -DNDEBUG -std=c++23 -Wall -Wextra -Wpedantic -Wshadow -Wnon-virtual-dtor -Wold-style-cast -Wcast-align -Wunused -Woverloaded-virtual -Wcast-qual -Wconversion -Wsign-conversion -Wnull-dereference -Wformat=2 -Wdangling-else -Werror -Wno-include-angled-in-module-purview -x c++ /home/mpusz/repos/mp-units/test/static/angular_test.cpp -c -o test/static/CMakeFiles/unit_tests_static.dir/Release/angular_test.cpp.o -resource-dir "/usr/lib/llvm-18/lib/clang/18" -MT test/static/CMakeFiles/unit_tests_static.dir/Release/angular_test.cpp.o.ddi -MD -MF test/static/CMakeFiles/unit_tests_static.dir/Release/angular_test.cpp.o.ddi.d > test/static/CMakeFiles/unit_tests_static.dir/Release/angular_test.cpp.o.ddi.tmp && mv test/static/CMakeFiles/unit_tests_static.dir/Release/angular_test.cpp.o.ddi.tmp test/static/CMakeFiles/unit_tests_static.dir/Release/angular_test.cpp.o.ddi
[build] Ubuntu clang version 18.1.8 (++20240701074744+3b5b5c1ec4a3-1~exp1~20240701194905.84)
[build] Target: x86_64-pc-linux-gnu
[build] Thread model: posix
[build] InstalledDir: /usr/bin
[build] Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/12
[build] Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/13
[build] Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/14
[build] Selected GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/14
[build] Candidate multilib: .;@m64
[build] Selected multilib: .;@m64
[build] Ubuntu clang version 18.1.8 (++20240701074744+3b5b5c1ec4a3-1~exp1~20240701194905.84)
[build] Target: x86_64-pc-linux-gnu
[build] Thread model: posix
[build] InstalledDir: /usr/bin
[build] Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/12
[build] Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/13
[build] Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/14
[build] Selected GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/14
[build] Candidate multilib: .;@m64
[build] Selected multilib: .;@m64
[build] clang -cc1 version 18.1.8 based upon LLVM 18.1.8 default target x86_64-pc-linux-gnu
[build] ignoring nonexistent directory "/usr/bin/../lib/gcc/x86_64-linux-gnu/14/../../../../x86_64-linux-gnu/include"
[build] ignoring nonexistent directory "/include"
[build] #include "..." search starts here:
[build] #include <...> search starts here:
[build] /home/mpusz/repos/mp-units/src/core/include
[build] /home/mpusz/repos/mp-units/src/systems/include
[build] /home/mpusz/.conan2/p/ms-gs972aa6e83ce46/p/include
[build] /usr/bin/../include/c++/v1
[build] /usr/lib/llvm-18/lib/clang/18/include
[build] /usr/local/include
[build] /usr/include/x86_64-linux-gnu
[build] /usr/include
[build] End of search list.
[build] Error while scanning dependencies for /home/mpusz/repos/mp-units/test/static/angular_test.cpp:
[build] In file included from /home/mpusz/repos/mp-units/test/static/angular_test.cpp:23:
[build] In file included from /home/mpusz/repos/mp-units/src/systems/include/mp-units/systems/isq_angle.h:28:
[build] In file included from /home/mpusz/repos/mp-units/src/systems/include/mp-units/systems/angular.h:27:
[build] In file included from /home/mpusz/repos/mp-units/src/systems/include/mp-units/systems/angular/math.h:25:
[build] In file included from /home/mpusz/repos/mp-units/src/core/include/mp-units/bits/requires_hosted.h:25:
[build] In file included from /home/mpusz/repos/mp-units/src/core/include/mp-units/bits/hacks.h:27:
[build] In file included from /usr/bin/../include/c++/v1/version:247:
[build] In file included from /usr/bin/../include/c++/v1/__assert:13:
[build] In file included from /usr/bin/../include/c++/v1/__assertion_handler:13:
[build] /usr/bin/../include/c++/v1/__config:13:10: fatal error: '__config_site' file not found
@mpusz I see this is running clang-scap-deps-18 -- are you able to reproduce the same error by running Clang directly instead? I think the following should do it:
/usr/bin/clang++-18 -DMP_UNITS_API_CONTRACTS=3 -DMP_UNITS_API_NO_CRTP=1 -DMP_UNITS_API_STD_FORMAT=1 -DMP_UNITS_API_STRING_VIEW_RET=1 -DMP_UNITS_HOSTED=1 -DCMAKE_INTDIR="Release" -I/home/mpusz/repos/mp-units/src/core/include -I/home/mpusz/repos/mp-units/src/systems/include -isystem /home/mpusz/.conan2/p/ms-gs972aa6e83ce46/p/include -m64 -stdlib=libc++ -v -O3 -DNDEBUG -std=c++23 -Wall -Wextra -Wpedantic -Wshadow -Wnon-virtual-dtor -Wold-style-cast -Wcast-align -Wunused -Woverloaded-virtual -Wcast-qual -Wconversion -Wsign-conversion -Wnull-dereference -Wformat=2 -Wdangling-else -Werror -Wno-include-angled-in-module-purview -x c++ /home/mpusz/repos/mp-units/test/static/angular_test.cpp -fsyntax-only -resource-dir "/usr/lib/llvm-18/lib/clang/18"
In your clang-scan-deps log above, I see the following headers:
[build] clang -cc1 version 18.1.8 based upon LLVM 18.1.8 default target x86_64-pc-linux-gnu
[build] ignoring nonexistent directory "/usr/x86_64-linux-gnu/include"
[build] ignoring nonexistent directory "/include"
[build] #include "..." search starts here:
[build] #include <...> search starts here:
[build] /home/mpusz/repos/mp-units/src/core/include
[build] /home/mpusz/repos/mp-units/src/systems/include
[build] /home/mpusz/.conan2/p/ms-gs972aa6e83ce46/p/include
[build] /usr/bin/../include/c++/v1
[build] /usr/lib/llvm-18/lib/clang/18/include
[build] /usr/local/include
[build] /usr/include/x86_64-linux-gnu
[build] /usr/include
Something looks incorrect here since we should be looking for /usr/bin/../include/x86_64-linux-gnu/c++/v1 as well.
@ldionne That's a Good catch! I confirm that I was able to compile the code without turning on the C++ module support. The problem seems to be in clang-scan-deps. It worked a few weeks ago.
Ok, so this is probably neither a packaging nor a libc++ issue, but instead a clang-scan-deps issue. I did git log release/18.x and couldn't find any obvious culprits.
Trying to ping some clang-scan-deps and modules folks: @jansvoboda11 @Bigcheese @ChuanqiXu9
Can anyone think of what might cause this? The TLDR is that a few weeks ago, clang-scan-deps-18 (which is built from the LLVM 18 release) stopped looking into the target-specific include directory in /usr/bin/../include/x86_64-linux-gnu/c++/v1 which means it fails to find libc++'s __config_site header.
@mpusz Since you're using Ubuntu I expect /usr/bin/clang-scan-deps-18 is a symlink to /usr/lib/llvm-18/bin/clang-scan-deps. When using symlinks the resource directory can't be found which does not work with modules. This has been resolved in clang-scan-deps-19. The solution for LLVM-18 is to use the absolute path to clang-scan-deps-18 in our build system.
The last time it worked for me was here: https://github.com/mpusz/mp-units/actions/runs/9517456102/job/26236105038. See "Create Conan package"
It also seemed to work on clang-17: https://github.com/mpusz/mp-units/actions/runs/9732819135/job/26932056092
At least before llvm-17 Ubuntu noble packages broke: https://github.com/mpusz/mp-units/actions/runs/9792077689/job/27037164301 😢 (probably I should submit another bug for it)
@ldionne I don't know what changed. However looking at @mpusz's logs there seems to be a different CMake version (at the patch level). I'm not sure when the clang-scan-deps issue was resolved exactly. @ChuanqiXu9 might know that.
BTW I see some other build issues due to __cpp_lib_format not being defined in libc++, which is (unfortunately) the correct status see #77773.
Yeah, __cpp_lib_format is not an issue. We made an error to not have separate feature test macros for those. However, #82780 could be fixed.
Ok, so wrapping up, it looks like we basically have a workaround for the issue and it has been fixed in LLVM 19. The workaround is to use an absolute path for clang-scan-deps-18.
Is that right? If so and if we agree there's nothing left that needs to be acted upon in this issue, let's close it.
I didn't check the workaround as I depend on CMake to call it correctly. I don't know how to force CMake to use the absolute path here.
Also, I am not sure if that is a correct summary. I was able to compile the code with clang-18 and modules enabled when I installed either libc++-17 (before it became broken) or libc++-19. It just does not work with libc++-18.
Can you show us the diff in what header files are installed by each version of libc++? Specifically, I'm interested in knowing the path of __config_site and related headers in these versions of the library.
libc++-19
ls -al /usr/include/c++/v1
lrwxrwxrwx 1 root root 32 Jul 3 09:19 /usr/include/c++/v1 -> ../../lib/llvm-19/include/c++/v1
ls -al /usr/include/c++/v1/__config_site
-rw-r--r-- 1 root root 1806 Jul 3 09:19 /usr/include/c++/v1/__config_site
libc++-17
ls -al /usr/include/c++/v1
lrwxrwxrwx 1 root root 32 Apr 14 11:03 /usr/include/c++/v1 -> ../../lib/llvm-17/include/c++/v1
ls -al /usr/include/c++/v1/__config_site
-rw-r--r-- 1 root root 1741 Apr 14 11:03 /usr/include/c++/v1/__config_site
It seems that there is a physical file (not a symbolic link) directly in the library tree for both of them.
Also, there is no x86_64-pc-linux-gnu directory for any of them:
ls /usr/lib/llvm-19/include/
CMakeLists.txt __libunwind_config.h clang clang-tidy libunwind.h llvm mach-o unwind_arm_ehabi.h
__cxxabi_config.h c++ clang-c cxxabi.h libunwind.modulemap llvm-c unwind.h unwind_itanium.h
Ok, so wrapping up, it looks like we basically have a workaround for the issue and it has been fixed in LLVM 19. The workaround is to use an absolute path for
clang-scan-deps-18.Is that right? If so and if we agree there's nothing left that needs to be acted upon in this issue, let's close it.
Leaving a broken package as the latest on the download page without at least a clear workaround note in the release notes (they will only see this if they search for obscure issue https://github.com/llvm/llvm-project/issues/96210) doesn't seem overly user friendly?
I didn't know this problem before.
Yes, there is
__config_sitein/usr/lib/llvm-18/include/x86_64-pc-linux-gnu/c++/v1but this is not the directory linked during installation:/usr/include/c++$ ls -al total 96 drwxr-xr-x 8 root root 4096 Jun 21 17:38 . drwxr-xr-x 75 root root 20480 Jun 21 17:38 .. drwxr-xr-x 12 root root 4096 May 27 11:30 14 lrwxrwxrwx 1 root root 32 Jun 15 09:01 v1 -> ../../lib/llvm-18/include/c++/v1There is no
__config_sitefile in/usr/include/c++/v1.
libc++-19
ls -al /usr/include/c++/v1 lrwxrwxrwx 1 root root 32 Jul 3 09:19 /usr/include/c++/v1 -> ../../lib/llvm-19/include/c++/v1 ls -al /usr/include/c++/v1/__config_site -rw-r--r-- 1 root root 1806 Jul 3 09:19 /usr/include/c++/v1/__config_sitelibc++-17
ls -al /usr/include/c++/v1 lrwxrwxrwx 1 root root 32 Apr 14 11:03 /usr/include/c++/v1 -> ../../lib/llvm-17/include/c++/v1 ls -al /usr/include/c++/v1/__config_site -rw-r--r-- 1 root root 1741 Apr 14 11:03 /usr/include/c++/v1/__config_site
So it looks like the difference between libc++-18 and (libc++-17 and libc++19) is that libc++-18 put some thing under x86_64-pc-linux-gnu.
