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

Distributed libLLVM conflicts with system libraries #55737

Open
rinon opened this issue Nov 7, 2018 · 5 comments
Open

Distributed libLLVM conflicts with system libraries #55737

rinon opened this issue Nov 7, 2018 · 5 comments
Labels
A-linkage Area: linking into static, shared libraries and binaries A-LLVM Area: Code generation parts specific to LLVM. Both correctness bugs and optimization-related issues. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.

Comments

@rinon
Copy link
Contributor

rinon commented Nov 7, 2018

Now that libLLVM.so is distributed with rust, we are unable to dynamically link a rust binary against a different libLLVM.so library. The rustlib directory containing libLLVM is 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:

cmd.include_path(&fix_windows_verbatim_for_gcc(&lib_path));

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)

@jonas-schievink jonas-schievink added A-linkage Area: linking into static, shared libraries and binaries A-LLVM Area: Code generation parts specific to LLVM. Both correctness bugs and optimization-related issues. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Jan 27, 2019
@emilio
Copy link
Contributor

emilio commented Mar 18, 2019

This should be fixed by #59173.

@rinon
Copy link
Contributor Author

rinon commented Mar 18, 2019

#59173 fixed this on Linux, thanks! The issue still persists on OS X because the filename is always libLLVM.dylib as mentioned above.

@Ionic
Copy link

Ionic commented Apr 20, 2019

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.dylib into the stage0-$arch/lib artifacts dir and use that via DYLD_LIBRARY_PATH, so subsequent usages of clang will fail to execute.

1.33.0 and prior didn't do this. They only created a librustc_codegen_llvm-llvm.dylib file as a later stage artifact (1? 2?), which didn't clash with system libraries.

@Ionic
Copy link

Ionic commented Apr 24, 2019

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.dylib file 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.

@Lord-Kamina
Copy link

I'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_PATH is equivalent to LD_LIBRARY_PATH and set it to whatever but it's actually not thes same. DYLD_LIBRARY_PATH is a hack and should not be used at all if possible because it overrides default system search paths. Instead, DYLD_FALLBACK_LIBRARY_PATH should be used; as those paths are only searched if a suitable library cannot be found in the default locations.

Sent with GitHawk

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-linkage Area: linking into static, shared libraries and binaries A-LLVM Area: Code generation parts specific to LLVM. Both correctness bugs and optimization-related issues. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Development

No branches or pull requests

5 participants