Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

'__config_site' file not found on Ubuntu noble for libc++-18 #96210

Open
mpusz opened this issue Jun 20, 2024 · 44 comments
Open

'__config_site' file not found on Ubuntu noble for libc++-18 #96210

mpusz opened this issue Jun 20, 2024 · 44 comments

Comments

@mpusz
Copy link

mpusz commented Jun 20, 2024

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.

@EugeneZelenko EugeneZelenko added libc++ libc++ C++ Standard Library. Not GNU libstdc++. Not libc++abi. packaging platform:linux and removed new issue labels Jun 20, 2024
@ldionne
Copy link
Member

ldionne commented Jun 20, 2024

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?

@mpusz
Copy link
Author

mpusz commented Jun 20, 2024

No, it is not there. The file is missing.

@ldionne
Copy link
Member

ldionne commented Jun 20, 2024

@tstellar Is LLVM responsible for those libc++-18-dev packages on Ubuntu?

@tstellar
Copy link
Collaborator

@sylvestre maintains this.

@ilovepi
Copy link
Contributor

ilovepi commented Jun 21, 2024

@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.

@chloro-pn
Copy link

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):
捕获

@ldionne
Copy link
Member

ldionne commented Jun 21, 2024

@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.

@mpusz
Copy link
Author

mpusz commented Jun 21, 2024

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.

@sammyj85
Copy link

Same issue: Ubuntu LLVM version 18.1.8.

Package is llvm-toolchain-jammy-18

@mpusz
Copy link
Author

mpusz commented Jun 30, 2024

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
Copy link
Member

@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.

@ldionne
Copy link
Member

ldionne commented Jul 3, 2024

@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.

@mpusz
Copy link
Author

mpusz commented Jul 3, 2024

@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

@ldionne
Copy link
Member

ldionne commented Jul 3, 2024

@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.

@mpusz
Copy link
Author

mpusz commented Jul 3, 2024

@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.

@ldionne
Copy link
Member

ldionne commented Jul 3, 2024

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.

@ldionne ldionne added clang-tools-extra and removed libc++ libc++ C++ Standard Library. Not GNU libstdc++. Not libc++abi. labels Jul 3, 2024
@ldionne
Copy link
Member

ldionne commented Jul 3, 2024

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.

@mordante
Copy link
Member

mordante commented Jul 4, 2024

@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.

@ldionne
Copy link
Member

ldionne commented Jul 4, 2024

@mordante Do you know what would have changed recently that broke this?

@mpusz
Copy link
Author

mpusz commented Jul 4, 2024

The last time it worked for me was here: https://github.com/mpusz/mp-units/actions/runs/9517456102/job/26236105038. See "Create Conan package"

@mpusz
Copy link
Author

mpusz commented Jul 4, 2024

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)

@mordante
Copy link
Member

mordante commented Jul 4, 2024

@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.

@mpusz
Copy link
Author

mpusz commented Jul 4, 2024

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.

@ldionne
Copy link
Member

ldionne commented Jul 4, 2024

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.

@mpusz
Copy link
Author

mpusz commented Jul 4, 2024

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.

@mpusz
Copy link
Author

mpusz commented Jul 4, 2024

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.

@ldionne
Copy link
Member

ldionne commented Jul 4, 2024

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.

@mpusz
Copy link
Author

mpusz commented Jul 4, 2024

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 

@sammyj85
Copy link

sammyj85 commented Jul 5, 2024

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 #96210) doesn't seem overly user friendly?

@ChuanqiXu9
Copy link
Member

I didn't know this problem before.

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.

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

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.

@sylvestre
Copy link
Collaborator

About

/usr/lib/llvm-18/include/x86_64-pc-linux-gnu/c++/v1

I think it is because I enabled LLVM_ENABLE_PER_TARGET_RUNTIME_DIR=ON this option in the pacakges to enable multiarch for this libs

@filippobrizzi
Copy link

This issue was not happening for me with version 18.1.6.
The problem is that current llvm installer allows to pin only the major version https://apt.llvm.org/ and when rebuilding my Docker image it upgraded Clang version and I don't know how to roll back.
Does anyone know how can I pin also the minor and patch version?
Thank you

@ldionne
Copy link
Member

ldionne commented Jul 9, 2024

About

/usr/lib/llvm-18/include/x86_64-pc-linux-gnu/c++/v1

I think it is because I enabled LLVM_ENABLE_PER_TARGET_RUNTIME_DIR=ON this option in the pacakges to enable multiarch for this libs

@sylvestre Since this seems to be the cause of the problem, can you undo that? It seems like that should not be a problem with LLVM 19 since clang-scan-deps is going to be fixed, but for LLVM 18 it's breaking folks.

@sylvestre
Copy link
Collaborator

@ldionne I could cherry pick the fix in clang-scan-deps? Do you know which one it is?

@ldionne
Copy link
Member

ldionne commented Jul 9, 2024

I can't find anything on release/18.x in clang or clang/tools/clang-scan-deps that would be the obvious culprit.

I know @MaskRay 's #80527 landed some months ago and that may help fix this issue, but I don't know for sure.

Folks on this issue mention that the issue wasn't happening with LLVM 18.1.6, but it is happening with LLVM 18.1.8. I looked at the very few commits between those two versions (git log llvmorg-18.1.6..llvmorg-18.1.8) and there's nothing that could be related to this. @sylvestre This means that you changed something about how you're building the release between these two tags. If we can't find how to actually fix clang-scan-deps, is there a reason for not simply undoing whatever was done between these two tags to unbreak everyone?

By the way, it would be really nice to have visibility into what the change was -- where's the code that controls that?

@sylvestre
Copy link
Collaborator

This is this commit:
https://salsa.debian.org/pkg-llvm-team/llvm-toolchain/-/commit/9ca35f30383d89e4fdd45d15e0eb82c832df4b8c
I did it to facilitate the multiarch support (ex: having the i386 on an amd64 system).
Otherwise, the install path is the same

@ldionne
Copy link
Member

ldionne commented Jul 9, 2024

@sylvestre Does the LLVM 19 package also contain that commit? I.e. are the APT packages for LLVM 19 also built with LLVM_ENABLE_PER_TARGET_RUNTIME_DIR=ON? If so, since folks are not seeing any issues with the LLVM 19 packages, it means that something was fixed on main (probably in clang, clang-scan-deps or something like that) that fixed the problem.

If the LLVM 19 packages are not built with LLVM_ENABLE_PER_TARGET_RUNTIME_DIR=ON (e.g. because you only landed your patch on the branch that controls the 18 release), then we have no information: it could be that LLVM_ENABLE_PER_TARGET_RUNTIME_DIR=ON also breaks a tip-of-trunk LLVM 19 toolchain.

In case the LLVM 19 package is indeed built with LLVM_ENABLE_PER_TARGET_RUNTIME_DIR=ON and it doesn't show any problem, I would strongly encourage undoing your patch on the LLVM 18 release since that is potentially causing more problems than it's solving.

@sylvestre
Copy link
Collaborator

19 doesn't have this change yet

@ldionne
Copy link
Member

ldionne commented Jul 9, 2024

Ok, so then we basically don't know whether LLVM 19 would be broken by enabling LLVM_ENABLE_PER_TARGET_RUNTIME_DIR=ON or not, but it's likely that it would since I haven't found anything that would fix it in clang or clang-scan-deps.

IMO, the best course of action would be to revert your change from LLVM 18 since it's actively breaking folks, and to investigate whether the same problem arises with LLVM tip-of-trunk with LLVM_ENABLE_PER_TARGET_RUNTIME_DIR=ON. If that's the case, we still have 2 weeks to fix this easily before the branch point.

@mpusz
Copy link
Author

mpusz commented Jul 13, 2024

@sylvestre, do we have any updates on this issue? Our CI has been failing for over three weeks because of it. This has already hidden some regressions in the project because we started to take failed CI for granted.

@sylvestre
Copy link
Collaborator

@mpusz I revert the fix. I will try to trigger the builds tomorrow (Sunday)

@stephanlachnit
Copy link

stephanlachnit commented Jul 14, 2024

I don't think that this is clang-scan-deps related, since we also got the issue with just using libc++-18-dev since it was built with LLVM_ENABLE_PER_TARGET_RUNTIME_DIR=ON in Debian Sid. I suspect LLVM 19 would also be affected with that option.

In particular, we use clang-16 with libc++-18-dev version 18.1.8-1 and it worked just fine, it only broke after the update to 18.1.8-2 that enabled the build option.

@stephanlachnit
Copy link

I also think this could be caused by https://bugs.debian.org/1075931, which includes a patch, but I haven't tested it.

@ldionne
Copy link
Member

ldionne commented Jul 15, 2024

Pinging @petrhosek since it seems that LLVM_ENABLE_PER_TARGET_RUNTIME_DIR might be kinda broken right now.

filippobrizzi added a commit to olympus-robotics/hephaestus that referenced this issue Aug 29, 2024
# Description
Move to Clang 17, this is needed due to
llvm/llvm-project#106204 and
llvm/llvm-project#96210 (comment).

In addition, we install `ssh` package.

---------

Co-authored-by: Filippo Brizzi <filippobrizzi@gmail.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests