-
Notifications
You must be signed in to change notification settings - Fork 13.6k
[Driver] Old compiler-rt library name (e.g. libclang_rt.builtins-aarch64.a) is reported when neither old/new library directory exists #87150
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
Comments
@llvm/issue-subscribers-clang-driver Author: YunQiang Su (wzssyqa)
When we build llvm with this cmd
It builds successfully, while if we try do something like
Something wrong happens
|
Maybe we should fix our build system to always set the directory to the normalized one? |
Are you building a x86-64 clang that produces aarch64 code on an x86-64 host? The command line does not look correct to me. I've used the following using
Newer Clang will not suggest |
Yes, the normal 'cross toolchain', just like (almost) all embedded cross toolchain with GCC.
It is not "normal" cross toolchain.
Yes. That's a bug then.
I have tried to fix this problem. See: #87319 |
In fact, it will fail even for native toolchain, if the -DLLVM_DEFAULT_TARGET_TRIPLE is given with a non-normalized triple. |
I think the issue is at I am testing a fix for |
@MaskRay This report is not about the wrong warning message. It is another problem. If llvm is configured with a non-normalized triple target, such as the triple-without-vendor section.
libclang_rt cannot be find then. In this case: libclang_rt is installed into /aarch64-linux-gnu, while clang try to find it in |
Follow-up to #81037. ToolChain::LibraryPaths holds the new compiler-rt library directory (e.g. `/tmp/Debug/lib/clang/19/lib/x86_64-unknown-linux-gnu`). However, it might be empty when the directory does not exist (due to the `if (getVFS().exists(P))` change in https://reviews.llvm.org/D158475). If neither the old/new compiler-rt library directories exists, we would suggest the undesired old compiler-rt file name: ``` % /tmp/Debug/bin/clang++ a.cc -fsanitize=memory -o a ld.lld: error: cannot open /tmp/Debug/lib/clang/19/lib/linux/libclang_rt.msan-x86_64.a: No such file or directory clang++: error: linker command failed with exit code 1 (use -v to see invocation) ``` With this change, we will correctly suggest the new compiler-rt file name. Fix #87150 Pull Request: #87866
@llvm/issue-subscribers-clang-driver Author: YunQiang Su (wzssyqa)
When we build llvm with this cmd
It builds successfully, while if we try do something like
Something wrong happens
|
Right. This are two issues. The clang driver issue about an imprecise error message (suggesting the old compiler-rt path) has been fixed by #87866. The CMake issue is about how to build
|
In fact compiler-rt is built, while it is present in a different path.
In fact,
will work well. |
Currently, clang looks for compiler-rt only from the normalized triple subdir. While if we are configured with a non-normalized triple with -DLLVM_DEFAULT_TARGET_TRIPLE, such as triples without vendor section, clang will fail to find compiler_rt. Let's look for compiler_rt from the subdir with name from --target option. To archive this, we add a new member called Origin to class Triple. Fixes: llvm#87150.
What's the different path? Can you name the paths to help readers understand the issue without building and debugging cmake or clang driver themselves? |
Follow-up to llvm#81037. ToolChain::LibraryPaths holds the new compiler-rt library directory (e.g. `/tmp/Debug/lib/clang/19/lib/x86_64-unknown-linux-gnu`). However, it might be empty when the directory does not exist (due to the `if (getVFS().exists(P))` change in https://reviews.llvm.org/D158475). If neither the old/new compiler-rt library directories exists, we would suggest the undesired old compiler-rt file name: ``` % /tmp/Debug/bin/clang++ a.cc -fsanitize=memory -o a ld.lld: error: cannot open /tmp/Debug/lib/clang/19/lib/linux/libclang_rt.msan-x86_64.a: No such file or directory clang++: error: linker command failed with exit code 1 (use -v to see invocation) ``` With this change, we will correctly suggest the new compiler-rt file name. Fix llvm#87150 Pull Request: llvm#87866
Follow-up to #81037. ToolChain::LibraryPaths holds the new compiler-rt library directory (e.g. `/tmp/Debug/lib/clang/19/lib/x86_64-unknown-linux-gnu`). However, it might be empty when the directory does not exist (due to the `if (getVFS().exists(P))` change in https://reviews.llvm.org/D158475). If neither the old/new compiler-rt library directories exists, we would suggest the undesired old compiler-rt file name: ``` % /tmp/Debug/bin/clang++ a.cc -fsanitize=memory -o a ld.lld: error: cannot open /tmp/Debug/lib/clang/19/lib/linux/libclang_rt.msan-x86_64.a: No such file or directory clang++: error: linker command failed with exit code 1 (use -v to see invocation) ``` With this change, we will correctly suggest the new compiler-rt file name. Fix #87150 Pull Request: #87866
Follow-up to llvm#81037. ToolChain::LibraryPaths holds the new compiler-rt library directory (e.g. `/tmp/Debug/lib/clang/19/lib/x86_64-unknown-linux-gnu`). However, it might be empty when the directory does not exist (due to the `if (getVFS().exists(P))` change in https://reviews.llvm.org/D158475). If neither the old/new compiler-rt library directories exists, we would suggest the undesired old compiler-rt file name: ``` % /tmp/Debug/bin/clang++ a.cc -fsanitize=memory -o a ld.lld: error: cannot open /tmp/Debug/lib/clang/19/lib/linux/libclang_rt.msan-x86_64.a: No such file or directory clang++: error: linker command failed with exit code 1 (use -v to see invocation) ``` With this change, we will correctly suggest the new compiler-rt file name. Fix llvm#87150 Pull Request: llvm#87866
Uh oh!
There was an error while loading. Please reload this page.
When we build llvm with this cmd
It builds successfully, while if we try do something like
Something wrong happens
libclang_rt.builtins-aarch64.a
does exists, while in a different path, with a different nameThe text was updated successfully, but these errors were encountered: