-
Notifications
You must be signed in to change notification settings - Fork 12.5k
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
self-contained linker: retry linking without -fuse-ld=lld
on CCs that don't support it
#125417
Conversation
@bors try |
self-contained linker: retry linking without `-fuse-ld=lld` on CCs that don't support it For the self-contained linker, this PR applies [the strategy](rust-lang#125330 (comment)) of retrying the linking step when the driver doesn't support `-fuse-ld=lld`, but with the option removed. This is the same strategy we already use of retrying when e.g. `-no-pie` is not supported. Fixes rust-lang#125330 r? `@petrochenkov` I have no idea how we could add a test here, much like we don't have one for `-no-pie` or `-static-pie` -- let me know if you have ideas -- but I tested on a CentOS7 image: ```console [root@d25b38376ede tmp]# ../build/host/stage1/bin/rustc helloworld.rs WARN rustc_codegen_ssa::back::link The linker driver does not support `-fuse-ld=lld`. Retrying without it. [root@d25b38376ede tmp]# readelf -p .comment helloworld String dump of section '.comment': [ 0] GCC: (GNU) 4.8.5 20150623 (Red Hat 4.8.5-44) [ 2d] rustc version 1.80.0-dev ``` (I wasn't able to test with `cross` as the issue describes: I wasn't able to reproduce that behavior locally. So I'll ask for help from the OP with a try build)
@VorpalBlade I couldn't test with Here, $ readelf -p .comment target/aarch64-unknown-linux-gnu/debug/helloworld
String dump of section '.comment':
[ 0] GCC: (Ubuntu 9.4.0-1ubuntu1~20.04.2) 9.4.0
[ 2b] rustc version 1.80.0-nightly (b92758a9a 2024-05-20)
[ 5f] GCC: (crosstool-NG UNKNOWN) 8.5.0 I don't know if you have another way to reproduce this issue that I could try? I've tested on a CentOS7 image with gcc 4.5 and a helloworld worked there, so I have high hopes it will fix your use-case but I'd like to make sure with an actual reproduction. Otherwise, I've asked CI to do a With rustup-toolchain-install-master, we can install CI artifacts and use them as regular rustup toolchains. When CI completes (the bot will post a message that the build was successful), To be honest I have a suspicion this might also fail, for unrelated reasons: I don't believe CI will build other std targets here, unfortunately. That seemed necessary in the cross-compilation use-case, but maybe cargo's |
r=me after testing what you want to test. |
☀️ Try build successful - checks-actions |
Let me try to cook something up with CI: @bors try |
self-contained linker: retry linking without `-fuse-ld=lld` on CCs that don't support it For the self-contained linker, this PR applies [the strategy](rust-lang#125330 (comment)) of retrying the linking step when the driver doesn't support `-fuse-ld=lld`, but with the option removed. This is the same strategy we already use of retrying when e.g. `-no-pie` is not supported. Fixes rust-lang#125330 r? `@petrochenkov` I have no idea how we could add a test here, much like we don't have one for `-no-pie` or `-static-pie` -- let me know if you have ideas -- but I tested on a CentOS7 image: ```console [root@d25b38376ede tmp]# ../build/host/stage1/bin/rustc helloworld.rs WARN rustc_codegen_ssa::back::link The linker driver does not support `-fuse-ld=lld`. Retrying without it. [root@d25b38376ede tmp]# readelf -p .comment helloworld String dump of section '.comment': [ 0] GCC: (GNU) 4.8.5 20150623 (Red Hat 4.8.5-44) [ 2d] rustc version 1.80.0-dev ``` (I wasn't able to test with `cross` as the issue describes: I wasn't able to reproduce that behavior locally. So I'll ask for help from the OP with a try build) try-job: dist-aarch64-linux try-job: dist-x86_64-linux
@lqd I will give this a try. As the build isn't done this evening and it is already pretty late, the next time I will have time to give this a try will be Friday evening, as tomorrow evening is DnD night (well actually not DnD, a different pen and paper RPG, but you get the point). |
@VorpalBlade The previous build is done. I just queued a new one in case I'd be able to get enough artifacts for cross-compiling. |
@lqd So: ❯ rustup-toolchain-install-master 5572f385cb1b21326f0cf6672b3f74a172b5dcfa
detecting the channel of the `5572f385cb1b21326f0cf6672b3f74a172b5dcfa` toolchain...
downloading <https://ci-artifacts.rust-lang.org/rustc-builds/5572f385cb1b21326f0cf6672b3f74a172b5dcfa/rustc-nightly-x86_64-unknown-linux-gnu.tar.xz>...
74.12 MB / 74.12 MB [=====================================================================================================================================================] 100.00 % 14.73 MB/s
downloading <https://ci-artifacts.rust-lang.org/rustc-builds/5572f385cb1b21326f0cf6672b3f74a172b5dcfa/rust-std-nightly-x86_64-unknown-linux-gnu.tar.xz>...
27.49 MB / 27.49 MB [======================================================================================================================================================] 100.00 % 2.99 MB/s
toolchain `5572f385cb1b21326f0cf6672b3f74a172b5dcfa` is successfully installed!
❯ cross +5572f385cb1b21326f0cf6672b3f74a172b5dcfa build --target aarch64-unknown-linux-gnu
error: error: invalid value '5572f385cb1b21326f0cf6672b3f74a172b5dcfa-x86_64-unknown-linux-gnu' for '<toolchain>...': invalid toolchain name: '5572f385cb1b21326f0cf6672b3f74a172b5dcfa-x86_64-unknown-linux-gnu'
For more information, try '--help'.
: invalid toolchain name: '5572f385cb1b21326f0cf6672b3f74a172b5dcfa-x86_64-unknown-linux-gnu'
Error:
0: couldn't install toolchain `5572f385cb1b21326f0cf6672b3f74a172b5dcfa-x86_64-unknown-linux-gnu`
1: `rustup toolchain add 5572f385cb1b21326f0cf6672b3f74a172b5dcfa-x86_64-unknown-linux-gnu --profile minimal` failed with exit status: 1
❯ rustup-toolchain-install-master 5572f385cb1b21326f0cf6672b3f74a172b5dcfa -t aarch64-unknown-linux-gnu
toolchain `5572f385cb1b21326f0cf6672b3f74a172b5dcfa` is already installed Expected? Any ideas on how to proceed? Would you would need the toolchain inside the docker image cross builds with? I'm not actually sure how cross works, I just used it as a tool. |
I don't know cross, so I couldn't tell you. It also seems to synthesize a toolchain name that makes no sense. And the last thing you tried is what I mentioned would fail (but here, it just ignored your request, as the toolchain was already installed, one would add the target with Trying to install the toolchain with a custom name like |
❯ cross +5572f385cb1b21326f0cf6672b3f74a172b5dcfa build --target aarch64-unknown-linux-gnu
Error:
0: `rustup target list --toolchain 5572f385cb1b21326f0cf6672b3f74a172b5dcfa-x86_64-unknown-linux-gnu` failed with exit status: 1
Stderr:
error: error: invalid value '5572f385cb1b21326f0cf6672b3f74a172b5dcfa-x86_64-unknown-linux-gnu' for '--toolchain <toolchain>': invalid toolchain name: '5572f385cb1b21326f0cf6672b3f74a172b5dcfa-x86_64-unknown-linux-gnu'
For more information, try '--help'.
: invalid toolchain name: '5572f385cb1b21326f0cf6672b3f74a172b5dcfa-x86_64-unknown-linux-gnu' Hm, not looking good with the custom name, and a different error too. We could try pinging the the developer involved in cross-rs/cross#1496 (the cross issue about the same thing), because a quick look through the wiki for cross didn't show any way to do this. @Emilgardis |
I tested this on the same kind of gcc that the cross docker images should contain, so it's not the end of the world if you don't know how I can reproduce the issue, or if cross can't use the CI artifacts. We think it should work, and you'd be able to test once it lands on master as a real toolchain, with the expected std for cross compilation of course. If it doesn't then you'd let us know :) |
(The invalid toolchain name is not from cross but from rustup) |
☀️ Try build successful - checks-actions |
@VorpalBlade the way to use the custom toolchain would be |
❯ rustup-toolchain-install-master 5572f385cb1b21326f0cf6672b3f74a172b5dcfa -t aarch64-unknown-linux-gnu
detecting the channel of the `5572f385cb1b21326f0cf6672b3f74a172b5dcfa` toolchain...
downloading <https://ci-artifacts.rust-lang.org/rustc-builds/5572f385cb1b21326f0cf6672b3f74a172b5dcfa/rustc-nightly-x86_64-unknown-linux-gnu.tar.xz>...
74.12 MB / 74.12 MB [=====================================================================================================================================================] 100.00 % 18.31 MB/s
downloading <https://ci-artifacts.rust-lang.org/rustc-builds/5572f385cb1b21326f0cf6672b3f74a172b5dcfa/rust-std-nightly-aarch64-unknown-linux-gnu.tar.xz>...
error: missing component `rust-std` on toolchain `5572f385cb1b21326f0cf6672b3f74a172b5dcfa` on channel `nightly` for target `aarch64-unknown-linux-gnu` Well that didn't seem to work either. I can either try again during Friday evening or when this has been merged to nightly. |
nevermind, seems rustup-toolchain-master installs the toolchains a bit different to cargo-bisect-rusct, and doesn't really work with Anyway, this pr should resolve the issue. |
It seems $ rustup +78c8355821161d05841b58cd7c27ff0bb679847d target add aarch64-unknown-linux-gnu
error: toolchain '78c8355821161d05841b58cd7c27ff0bb679847d' does not support components However, if it can accept a ready-made toolchain (and rustup doesn't fail when listing targets like we had above):
agreed |
Alrighty. We can't test with cross until this lands, we know it works on CentOS7, and it should it fix it there too. @bors r=petrochenkov |
…iaskrgr Rollup of 8 pull requests Successful merges: - rust-lang#122665 (Add some tests for public-private dependencies.) - rust-lang#123623 (Fix OutsideLoop's error suggestion: adding label `'block` for `if` block.) - rust-lang#125054 (Handle `ReVar` in `note_and_explain_region`) - rust-lang#125156 (Expand `for_loops_over_fallibles` lint to lint on fallibles behind references.) - rust-lang#125222 (Migrate `run-make/issue-46239` to `rmake`) - rust-lang#125316 (Tweak `Spacing` use) - rust-lang#125392 (Wrap Context.ext in AssertUnwindSafe) - rust-lang#125417 (self-contained linker: retry linking without `-fuse-ld=lld` on CCs that don't support it) r? `@ghost` `@rustbot` modify labels: rollup
Rollup merge of rust-lang#125417 - lqd:lld-retry, r=petrochenkov self-contained linker: retry linking without `-fuse-ld=lld` on CCs that don't support it For the self-contained linker, this PR applies [the strategy](rust-lang#125330 (comment)) of retrying the linking step when the driver doesn't support `-fuse-ld=lld`, but with the option removed. This is the same strategy we already use of retrying when e.g. `-no-pie` is not supported. Fixes rust-lang#125330 r? `@petrochenkov` I have no idea how we could add a test here, much like we don't have one for `-no-pie` or `-static-pie` -- let me know if you have ideas -- but I tested on a CentOS7 image: ```console [root@d25b38376ede tmp]# ../build/host/stage1/bin/rustc helloworld.rs WARN rustc_codegen_ssa::back::link The linker driver does not support `-fuse-ld=lld`. Retrying without it. [root@d25b38376ede tmp]# readelf -p .comment helloworld String dump of section '.comment': [ 0] GCC: (GNU) 4.8.5 20150623 (Red Hat 4.8.5-44) [ 2d] rustc version 1.80.0-dev ``` I wasn't able to test with `cross` as the issue describes: I wasn't able to reproduce that behavior locally.
Works fine with nightly and cross now. Thanks! |
For the self-contained linker, this PR applies the strategy of retrying the linking step when the driver doesn't support
-fuse-ld=lld
, but with the option removed. This is the same strategy we already use of retrying when e.g.-no-pie
is not supported.Fixes #125330
r? @petrochenkov
I have no idea how we could add a test here, much like we don't have one for
-no-pie
or-static-pie
-- let me know if you have ideas -- but I tested on a CentOS7 image:I wasn't able to test with
cross
as the issue describes: I wasn't able to reproduce that behavior locally.