Repository navigation
Distributed libLLVM conflicts with system libraries #55737
Description
Activity
This is not just a redistribution problem, but also leads to a general FTBFS while bootstrapping with clang compilers since rust 1.34.0.
1.34.0 now seems to put
libLLVM.dylibinto thestage0-$arch/libartifacts dir and use that viaDYLD_LIBRARY_PATH, so subsequent usages ofclangwill fail to execute.1.33.0 and prior didn't do this. They only created a
librustc_codegen_llvm-llvm.dylibfile as a later stage artifact (1? 2?), which didn't clash with system libraries.I'm stupid - rust isn't compiling its own version of
llvm- at least not when passing--llvm-root.The problem is that the precompiled 1.33 binaries that are used to bootstrap rust contain a
libLLVM.dylibfile which makes compiling with clang impossible since the rust-root lib directory is added to the dynamic linker library path, overriding the correct LLVM library.Reacted by Gregorio LitensteinI'm stupid - rust isn't compiling its own version of
llvm- at least not when passing--llvm-root. ...@Ionic The problem is most likely the same in as in cargo, people assume
DYLD_LIBRARY_PATHis equivalent toLD_LIBRARY_PATHand set it to whatever but it's actually not thes same.DYLD_LIBRARY_PATHis a hack and should not be used at all if possible because it overrides default system search paths. Instead,DYLD_FALLBACK_LIBRARY_PATHshould be used; as those paths are only searched if a suitable library cannot be found in the default locations.Sent with GitHawk
Triage: Is this still a problem?
Now that
libLLVM.sois distributed with rust, we are unable to dynamically link a rust binary against a differentlibLLVM.solibrary. The rustlib directory containinglibLLVMis prepended to the linker search path, and I don't see a good way to ask cargo to add a search path earlier than the rustlib is added. It looks to me like the rustlib directory is added here:rust/src/librustc_codegen_llvm/back/link.rs
Line 1044 in 15d7704
I noticed that support for appending a suffix to the LLVM libs was added in #53987. Can we turn that on for CI so the prebuilt distributions have a suffix on the library?
Unfortunately, the suffix won't actually fix this issue on MacOS, since the LLVM build does not append the suffix (or any version info) to the name of the dynamic library when building on MacOS: (see https://github.com/rust-lang/llvm/blob/7051ead40a5f825878b59bf08d4e768be9e99a4a/cmake/modules/AddLLVM.cmake#L520)