-
Notifications
You must be signed in to change notification settings - Fork 12.8k
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
Problem linking libunwind when compiling clippy #85751
Comments
Can you try using the following flags: |
cc @12101111 |
The linking command line is assembled in linker_with_args This is the end part of linking command, and the are added to command line by link_local_crate_native_libs_and_dependent_crate_libs:
This part, among all
And compiler_builtins is alaways the last object file added here: rust/compiler/rustc_codegen_ssa/src/back/link.rs Lines 1952 to 1959 in df3d86b
This part is handled by add_upstream_native_libraries
But which crate link to Can you apply this patch: --- a/compiler/rustc_codegen_ssa/src/back/link.rs
+++ b/compiler/rustc_codegen_ssa/src/back/link.rs
@@ -2157,6 +2157,7 @@ fn add_upstream_native_libraries(
last = if (lib.kind, lib.name) == last { continue } else { (lib.kind, lib.name) };
let verbatim = lib.verbatim.unwrap_or(false);
+ info!("link native lib: {:?} from crate #{}", lib, codegen_results.crate_info.crate_name[&cnum]);
match lib.kind {
NativeLibKind::Dylib { as_needed } => {
cmd.link_dylib(name, verbatim, as_needed.unwrap_or(true)) and rebuild rustc and clippy with this:
It should output like this:
|
(Note: wrote this reply before seeing 12101111's response, which I am still digesting. This is in response to petrhosek's comment) Thanks! I'm working on following your suggestion. I thought I could do this by modifying rustflags in src/tools/clippy/.cargo/config:
But that cargo config doesn't seem to be picked up when we build clippy, because the link command, and the associated error, seems to be the same as what I posted above. The overall build command we are using in the docker image is:
|
Working on following 12101111's instructions. This will be a little complicated because, if I understand correctly, I need to patch and rebuild the beta rustc, because that's what's used to build the nightly. So I need to compile the compiler to compile my compiler. :) |
You don't need build beta compiler, stage1 will contain this change and that's enough https://rustc-dev-guide.rust-lang.org/building/bootstrapping.html |
OK. I am surprised by that, because the "cargo build" command for clippy uses the version of cargo in the beta toolchain (see my earlier comment) |
You should build rust toolchain using |
output from "Building stage1 tool clippy-driver" to the linker error: This was built as described above. I am inquiring as to why we are not doing |
There should be lines that contain the log from clippy crate: |
I checked all the output I have from the build command. There are no instances of "preparing Executable to.*clippy". Are you sure I don't need to apply your patch to the beta compiler? As I said, clippy seems to be getting built using "cargo build" from the beta compiler. It looks like we may be setting this explicitly in our config.toml:
I'm going to try patching and rebuilding the beta toolchain. |
Here's the output with the patch applied to the beta toolchain, but not the nightly (I hope I don't need it applied to both, but if so I can do that next) This does contain the following lines which may be of interest to you based on your earlier comment:
But I'm not sure this adds much new information, because the linker command and error were in my original report. |
Full output from building rustc, clippy, etc. after building llvm (a superset of the file above) |
This looks suspicious:
Our llvm.cflags include |
Nope, that wasn't it. |
rust/compiler/rustc_llvm/build.rs Line 216 in f58631b
rust/compiler/rustc_llvm/build.rs Lines 248 to 252 in f58631b
Lines 677 to 680 in f58631b
Could you try to remove |
Without I wonder if this is because we are deleting libunwind.so as a hack to force static linking? |
A theory about what's going on here: Based on the code snippets for how We're specifying |
I was able to get it build by hacking
|
@12101111 thanks for your help. Let me know if you want me to patch in anything to test. |
I am not sure the status of this issue. it looks like you did get clippy working? Regardless, "deleting libunwind.so in the sysroot and then building rustc" is not a use case we're going to support, so I'm going to close this. |
We are building the Rust compiler from nightly, from which we define a Bazel toolchain.
In addition to rustc, the toolchain includes other tools, such as clippy and rustfmt, which we build as well.
We require the binaries to be statically linked, so they are self-contained and do not depend on shared libraries.
In particular, we need to statically link the version of libunwind that gets built when compiling llvm.
So in config.toml we have
Then, after compiling llvm, we hackishly force static linking by removing the .so:
rm llvm/lib/libunwind.so*
. This works around #29527This works for rustc and rustfmt, but not clippy. It seems that clippy is not being told to use the in-tree version of libunwind, and so we get a linker error:
(using
<BD>
for brevity to indicate the common build directory path)Additional information:
The text was updated successfully, but these errors were encountered: