-
Notifications
You must be signed in to change notification settings - Fork 13.6k
Closed
Labels
A-LLVMArea: Code generation parts specific to LLVM. Both correctness bugs and optimization-related issues.Area: Code generation parts specific to LLVM. Both correctness bugs and optimization-related issues.C-bugCategory: This is a bug.Category: This is a bug.P-criticalCritical priorityCritical priorityT-bootstrapRelevant to the bootstrap subteam: Rust's build system (x.py and src/bootstrap)Relevant to the bootstrap subteam: Rust's build system (x.py and src/bootstrap)regression-from-stable-to-betaPerformance or correctness regression from stable to beta.Performance or correctness regression from stable to beta.
Milestone
Description
Since 1.48 beta, x.py install
is now installing libLLVM.so even when dynamically linking against the system one.
Not only that, the install path is unaware of the target architecture, which breaks during cross-compiling. I am not sure exactly what happens - possibly (a) the host is installed instead of the target or (b) both are installed, and the host clobbers the target - in any case the end result I observe is that the host-arch libLLVM.so ends up in the install directory instead of the target-arch one, which would be correct.
cuviper
Metadata
Metadata
Assignees
Labels
A-LLVMArea: Code generation parts specific to LLVM. Both correctness bugs and optimization-related issues.Area: Code generation parts specific to LLVM. Both correctness bugs and optimization-related issues.C-bugCategory: This is a bug.Category: This is a bug.P-criticalCritical priorityCritical priorityT-bootstrapRelevant to the bootstrap subteam: Rust's build system (x.py and src/bootstrap)Relevant to the bootstrap subteam: Rust's build system (x.py and src/bootstrap)regression-from-stable-to-betaPerformance or correctness regression from stable to beta.Performance or correctness regression from stable to beta.
Type
Projects
Relationships
Development
Select code repository
Activity
infinity0 commentedon Nov 10, 2020
@Mark-Simulacrum Possibly to do with the new RustDev component and especially this snippet:
This is a regression; 1.47 had the correct behaviour of not trying to install LLVM at all. Note that I am not explicitly referencing RustDev at all, I am just calling
x.py install
.Mark-Simulacrum commentedon Nov 10, 2020
I plan to investigate fixing this soon, I think it's important we get this fixed.
Could you provide instructions on how to verify things are working so I can check locally? (I guess I can compare against a 1.47 build but would be good to get what command you're running).
infinity0 commentedon Nov 11, 2020
in config.toml:
then with
x.py install
, the tarballs shouldn't contain a libLLVM.so but they do.The documentation for llvm-config says "Note that if this is specified we don't compile LLVM at all for this target." - so possibly this bug can be fixed simply by changing this snippet in
src/bootstrap/dist.rs
:to check for whether
llvm-config
was set or not.infinity0 commentedon Nov 11, 2020
The cross-compiling wrong-location/clobbering issue still exists as I described in the OP, but it does not affect my use-case since we're not installing libLLVM.so.
On Debian we are in fact moving everything from
/usr/lib
to/usr/lib/${gnu_arch_triplet}
afterx.py install
, but I am not sure how cross-platform this is for you to adopt. I'm also not sure why it is the libLLVM.so specifically that ends up with the wrong architecture, but the other libraries (e.g. libstd.so) are fine.cuviper commentedon Nov 12, 2020
I think it was actually #76349's commit a7b092f that changed this, specifically around here:
a7b092f#diff-2c56335faa24486df09ba392d8900c57e2fac4633e1f7038469bcf9ed3feb871L2395
Before, we would only copy
libLLVM.so
if it was found in thesrc_libdir
. Now it copies everything thatllvm-config --libfiles
says, even if thatllvm-config
is external. I also see thatprebuilt_llvm_config
has a short path for customllvm-config
:rust/src/bootstrap/native.rs
Lines 45 to 52 in 5404efc
I think it would work to change
maybe_install_llvm
to skip out on customllvm-config
, as @infinity0 suggests.Mark-Simulacrum commentedon Nov 12, 2020
Though one could argue that is wrong (in some cases) right? That is, if you don't copy, it'll not work unless the original location is in LD_LIBRARY_PATH or equivalent.
I'd be fine changing/reverting to not copy on custom llvm though, that seems like the right fix for now - it seems rare to have custom LLVM and want the copy.
Mark-Simulacrum commentedon Nov 12, 2020
Filed #78986 with the suggested fix here.
cuviper commentedon Nov 12, 2020
I see it the same as any other system library that we might link against. e.g. Cargo links to the system openssl by default, and we don't try to pull that into dist tarballs.
Mark-Simulacrum commentedon Nov 12, 2020
Good point :)
Rollup merge of rust-lang#78986 - Mark-Simulacrum:fix-llvm, r=alexcri…
Auto merge of rust-lang#79074 - Mark-Simulacrum:fix-ci-llvm, r=jyn514