-
Notifications
You must be signed in to change notification settings - Fork 13k
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
clang-scan-deps unable to find system headers in p1689 format #61006
Comments
@llvm/issue-subscribers-clang-modules |
What is the path of I can reproduce this if I make a symbolic link of the real clang in another directory. Since the clang-scan-deps won't invoke If this works for you, I'd like to update the document. |
Not OP, but is was having the same issue exclusively on Ubuntu when installing the latest snapshot package via APT. By default the package seems to create a broken link: After adding Is this behavior expected? |
I did some more testing, using the good case with Your suggestion to use the real path instead of a symlink works too. I think it would be nice if |
I've created https://reviews.llvm.org/D144894 |
> clang -print-resource-dir clang knows where stddef.h is. |
Thanks for the info, this seems to work when using the symlink too. Maybe then it's trivial to fix. @ChuanqiXu9 if you want I can take a look at it. |
I'll be pretty appreciated if you can look at it :) |
I am trying to use clang-scan-deps from LLVM 16 as the scanner for gcc. Use the same code and replace $ /opt/llvm-16/bin/clang-scan-deps -format=p1689 -- /usr/bin/g++ -std=c++20 -x c++ test.cppm -c -o /tmp/test.cppm.o
Error while scanning dependencies for test.cppm:
In file included from test.cppm:3:
In file included from /usr/bin/../lib64/gcc/x86_64-suse-linux/13/../../../../include/c++/13/vector:80:
In file included from /usr/bin/../lib64/gcc/x86_64-suse-linux/13/../../../../include/c++/13/bits/memory_resource.h:38:
/usr/bin/../lib64/gcc/x86_64-suse-linux/13/../../../../include/c++/13/cstddef:50:10: fatal error: 'stddef.h' file not found
{
"revision": 0,
"rules": [],
"version": 1
} On my system, Manually adding |
Experiencing the same issue with Ubuntu 22.04 clang-17 nightly packages.
My current workaround: |
Can confirm this for Clang16:
although I only have these folders:
|
Not working yet due to `CMAKE_CXX_COMPILER_CLANG_SCAN_DEPS-NOTFOUND`. Useful links: - https://github.com/Kitware/CMake/blob/master/Help/dev/experimental.rst - llvm/llvm-project#61006 (comment) - https://stackoverflow.com/a/61244367/9655481
I have similar issue using clang-scan-deps with Apple Clang and macOS SDK. Leaving information in case it's helpful for fixing or for folks to find this issue.
The command following
In
A temporary sloppy workaround, at user side of clang-scan-deps, could be adding this directory to |
Sadly, the above patch is incorrect strictly. To solve the issue manually, we can pass |
Address #61006. The actual reason for the issue is about the usage of clang-scan-deps instead of its functionalities since clang-scan-deps has already considered the problem before for clang modules. So this patch tries to document the corresponding solution and add a test case for it to address the issue.
Now I feel it is primarily a usage issue and we can't do a lot inside the clang-scan-deps itself. So I update the document (https://clang.llvm.org/docs/StandardCPlusPlusModules.html#possible-issues-failed-to-find-system-headers) and I am going to close the issue itself since there may not be more things to do in our repo. While it is indeed user-infriendly and annoying, since clang-scan-deps is mainly used by build systems, so we can hope build systems to handle this well. Then we should file issues with corresponding build systems. |
The issue for cmake I registered is https://gitlab.kitware.com/cmake/cmake/-/issues/25180 |
Automated commit created by applying diff 549726 Phabricator-ID: PHID-HMBT-3hxbcvj4law6shs3llt3 Review-ID: D157817
This patch solves two problems with the recently added test, which caused CI failure in an internal downstream system: 1. It connects subsequent `RUN` statements with `&&` into a single statement; otherwise, the variable defined in the first of them is out of scope in the subsequent ones where it is used. 2. In our hermetic testing environment, the clang++ binary under test does not have access to standard include paths (`/usr/include` etc.), so the test fails because it does not find `stddef.h`. The patch thus changes the test to use a locally created `a.h` header file. Differential Revision: https://reviews.llvm.org/D157817
Many thanks. I also encountered the similar error, which I used clang 17 and CMake 3.28 to compile a simple hello world project with c++20 modules, it also worked for me after adding |
Hello! If I use /usr/bin/clang , then the project will be built without adding a flag "-I/usr/lib/clang/17/include", but when setting up cmake there will be the following messages: [proc] The command: clang -v exited with code: 1 I'm using Fedora 39. |
I don't get your point quite a lot. For the problem of failed to find , we recorded it here: https://clang.llvm.org/docs/StandardCPlusPlusModules.html#possible-issues-failed-to-find-system-headers. And if there are other problems, I think a new issue may be worthy. |
I'm having the same issue in Fedora 40. When trying to invoke |
While testing modules with CMake I ran into an issue that some system headers are not found.
I tested with
Debian clang version 17.0.0 (++20230226071743+b8df886c1e2a-1~exp1~20230226071846.576)
And this code
Compilation with Clang succeeds
But testing with the dependency scanner
Fails with the following output
The line where the header is not found uses
#include_next <stddef.h>
to includestddef.h
.I get similar errors when I don't specify libc++ and use libstdc++.
The text was updated successfully, but these errors were encountered: