Skip to content

1.48 beta installer spuriously installing libLLVM.so, also into the incorrect location #78932

@infinity0

Description

@infinity0
Contributor

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.

Activity

infinity0

infinity0 commented on Nov 10, 2020

@infinity0
ContributorAuthor

@Mark-Simulacrum Possibly to do with the new RustDev component and especially this snippet:

        // Copy libLLVM.so to the target lib dir as well, so the RPATH like
        // `$ORIGIN/../lib` can find it. It may also be used as a dependency
        // of `rustc-dev` to support the inherited `-lLLVM` when using the
        // compiler libraries.
        maybe_install_llvm(builder, target, &image.join("lib"));

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.

added this to the 1.48.0 milestone on Nov 10, 2020
Mark-Simulacrum

Mark-Simulacrum commented on Nov 10, 2020

@Mark-Simulacrum
Member

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).

added
T-bootstrapRelevant to the bootstrap subteam: Rust's build system (x.py and src/bootstrap)
A-LLVMArea: Code generation parts specific to LLVM. Both correctness bugs and optimization-related issues.
on Nov 11, 2020
infinity0

infinity0 commented on Nov 11, 2020

@infinity0
ContributorAuthor

in config.toml:

[llvm]
link-shared = true
[target]
llvm-config = "/usr/lib/llvm-11/bin/llvm-config"

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:

    if !builder.config.llvm_link_shared {
        // We do not need to copy LLVM files into the sysroot if it is not
        // dynamically linked; it is already included into librustc_llvm
        // statically.
        return;
    }

to check for whether llvm-config was set or not.

infinity0

infinity0 commented on Nov 11, 2020

@infinity0
ContributorAuthor

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} after x.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

cuviper commented on Nov 12, 2020

@cuviper
Member

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 the src_libdir. Now it copies everything that llvm-config --libfiles says, even if that llvm-config is external. I also see that prebuilt_llvm_config has a short path for custom llvm-config:

// If we're using a custom LLVM bail out here, but we can only use a
// custom LLVM for the build triple.
if let Some(config) = builder.config.target_config.get(&target) {
if let Some(ref s) = config.llvm_config {
check_llvm_version(builder, s);
return Ok(s.to_path_buf());
}
}

I think it would work to change maybe_install_llvm to skip out on custom llvm-config, as @infinity0 suggests.

Mark-Simulacrum

Mark-Simulacrum commented on Nov 12, 2020

@Mark-Simulacrum
Member

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

Mark-Simulacrum commented on Nov 12, 2020

@Mark-Simulacrum
Member

Filed #78986 with the suggested fix here.

cuviper

cuviper commented on Nov 12, 2020

@cuviper
Member

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

Mark-Simulacrum commented on Nov 12, 2020

@Mark-Simulacrum
Member

Good point :)

added a commit that references this issue on Nov 15, 2020
e3d52b8
added a commit that references this issue on Nov 16, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Labels

A-LLVMArea: Code generation parts specific to LLVM. Both correctness bugs and optimization-related issues.C-bugCategory: This is a bug.P-criticalCritical priorityT-bootstrapRelevant 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.

Type

No type

Projects

No projects

Relationships

None yet

    Development

    Participants

    @cuviper@infinity0@Mark-Simulacrum@jyn514

    Issue actions

      1.48 beta installer spuriously installing libLLVM.so, also into the incorrect location · Issue #78932 · rust-lang/rust