Rust's libLLVM-8.so doesn't work with clang #59034
Comments
estebank
added
A-LLVM
|
Is EDIT: oh you wrote that in the report already. I remember there being an issue like this in cargo repo from a long long time ago, but cannot find it now. |
|
See also #55737. We should probably set a custom suffix per #53987. Maybe even include the Rust version to help avoid bootstrap issues like what commit 2d21df8 saw. (cc @Mark-Simulacrum) |
|
Yep, I think a suffix of rust version (or maybe LLVM submodule commit?) would be good. I think we'd appreciate a PR for something like that; I would expect it to be a matter of making the version suffix default be |
|
Sure, that sounds good, I can give that a shot. |
|
I sent #59173 with a change that I hope will address this, but see there why I cannot confirm it will :) |
I used version-channel-sha, hopefully that should work. I checked that bootstrap builds, but I cannot check anything else since the llvm build process is started from cargo, and thus calls clang, and thus I hit the same bug I hope to fix with this change. Hopefully fixes rust-lang#59034.
|
triage: P-high, assigning to @emilio |
bootstrap: Default to a sensible llvm-suffix. I used version-channel-sha, hopefully that should work. I checked that bootstrap builds, but I cannot check anything else since the llvm build process is started from cargo, and thus calls clang, and thus I hit the same bug I hope to fix with this change. Hopefully fixes rust-lang#59034.
I used version-channel-sha, hopefully that should work. I checked that bootstrap builds, but I cannot check anything else since the llvm build process is started from cargo, and thus calls clang, and thus I hit the same bug I hope to fix with this change. Hopefully fixes rust-lang#59034.
bootstrap: Remove commit hash from LLVM version suffix to avoid rebuilds The custom LLVM version suffix was introduced to avoid unintentional library names conflicts. By default it included the LLVM submodule commit hash. Changing the version suffix requires the complete LLVM rebuild, and since then every change to the submodules required it as well. Remove the commit hash from version suffix to avoid complete rebuilds, while leaving the `rust` string, the release number and release channel to disambiguate the library name. Context: version suffix was introduced by rust-lang#59173 as solution to rust-lang#59034. Resolves rust-lang#68715.
Which means that programs that run
clangfrom a build script, or from cargo in some other way, fail.Steps to Reproduce:
0. Have a clang binary pointing to clang-8 installed and in your path.
Actual results: /usr/bin/clang: relocation error: /lib64/libclangBasic.so.8: symbol _ZTIN4llvm14FoldingSetBaseE version LLVM_8 not defined in file libLLVM-8.so with link time reference
Expected results: not so
This only happens if ran from cargo, if I run the test executable manually then stuff works, so I suspect this is some LD_LIBRARY_PATH mungling that cargo or rustup do under the hood.
This is technically a regression from #58408, same problem does not exist with rust stable / beta and clang 7.
There's a slight chance that there's an issue on how clang-8 is built in Fedora, so I also filed https://bugzilla.redhat.com/show_bug.cgi?id=1687047, but I think it's unexpected that clang when called from cargo / build scripts uses rust's libLLVM.so, and probably should be avoided.
cc @alexcrichton
The text was updated successfully, but these errors were encountered: