integration-test: Set rust-lld as a linker only on macOS
#908
Conversation
✅ Deploy Preview for aya-rs-docs ready!Built without sensitive environment variables
To edit notification comments on pull requests, go to your Netlify site configuration. |
vadorovsky
force-pushed
the
integration-tests-linker
branch
from
3c4f45c
to
b3842e3
Compare
vadorovsky
changed the title
vadorovsky
force-pushed
the
integration-tests-linker
branch
3 times, most recently
from
c3a1ecf
to
0107a99
Compare
|
Is this no longer necessary? |
I would say it's still necessary. I'm still facing the same issue when I'm building integration tests on any musl-based system. I asked Rust community about that here rust-lang/rust#130062 and the conclusion is basically: "you're supposed to use the C compiler driver as the linker, as it knows where to find these libraries" It's still a mystery for me why Let me rebase it. The red builds are still the old ones from September, unrelated to the PR itself. |
|
On a side note, Rust nightly is currently using rust-lld by default (but still through the system C compiler which figures out the paths). If they decide to ship that in any stable version, we won't have to touch any RUSTFLAGS here anymore. |
vadorovsky
force-pushed
the
integration-tests-linker
branch
from
0107a99
to
c0a7b7f
Compare
|
Ubuntu fails now because of old clang. I also noticed just now that we are entering the Taking a step back, I'm starting to doubt whether we should mangle with the linkers and linker flags at all in this place. Our default cargo configuration specifies the cross gcc wrappers as linkers, which should be good enough for Ubuntu/Debian/Fedora users even for cross-compilation scenarios. People wanting to link with clang+lld could just define their own RUSTFLAGS (at least I'm fine with doing that,). I will give it a try now, but if not touching the flags is going to work both on Ubuntu and macOS, then I think that would be a solution. |
That doesn't sound right. Are you sure?
How is |
Nevermind, that's not true. What doesn't work is building/running VM tests (on musl/Linux host). In that case After the following change: diff --git a/xtask/src/run.rs b/xtask/src/run.rs
index 8bba7a5..b6e4b2a 100644
--- a/xtask/src/run.rs
+++ b/xtask/src/run.rs
@@ -59,8 +59,7 @@ where
let mut cmd = Command::new("cargo");
cmd.args(["build", "--message-format=json"]);
if let Some(target) = target {
- let config = format!("target.{target}.linker = \"rust-lld\"");
- cmd.args(["--target", target, "--config", &config]);
+ cmd.args(["--target", target]);
}
f(&mut cmd);It works. At least for the x86_64 scenario, where my default C toolchain is picked up. For cross scenarios, I would need to set up RUSTFLAGS manually to pick up clang+lld, but it's fine. I just don't want xtask automatically switching to rust-lld in that case. I also checked whether that change works on Ubuntu and it also works fine. Using C compiler as linker indeed looks like the best approach for Linux.
I see. I guess that I tried whether the combination of So I guess that we could apply |
vadorovsky
force-pushed
the
integration-tests-linker
branch
from
c0a7b7f
to
ce23f2e
Compare
The recommendation (coming from rust-lang/rust#130062) for Linux hosts is using C compiler driver as a linker, which is able to find system-wide libraries. Using linker binaries directly in `-C linker` (e.g. `-C linker=rust-lld`) often results in errors like: ``` cargo:warning=error: linking with `rust-lld` failed: exit status: 1ger, ppv-lite86, libc... cargo:warning= | cargo:warning= = note: LC_ALL="C" PATH="/home/vadorovsky/.rustup/toolchains/stable-x86_64-un cargo:warning= = note: rust-lld: error: unable to find library -lgcc_s cargo:warning= rust-lld: error: unable to find library -lc cargo:warning= cargo:warning= cargo:warning= cargo:warning=error: aborting due to 1 previous error ``` Not touching the linker settings is usually the best approach for Linux systems. Native builds pick up the default C toolchain. Cross builds default to GCC cross wrapper, but that's easy to supress with clang and lld using RUSTFLAGS. However, `-C linker=rust-lld` still works the best on macOS, where Rust toolchains come with unwinder and runtime and there is usually no need to link system libraries. Keep setting it only for macOS. Fixes aya-rs#907
vadorovsky
force-pushed
the
integration-tests-linker
branch
from
ce23f2e
to
52045f7
Compare
vadorovsky
changed the title
rust-lld as a linker only on macOS
vadorovsky
force-pushed
the
integration-tests-linker
branch
from
52045f7
to
89098e3
Compare
|
Thanks for the detail. Let's give it a shot. Can we add a CI job that verifies that everything works as expected? |
vadorovsky
force-pushed
the
integration-tests-linker
branch
3 times, most recently
from
6c0bf0e
to
18aa37c
Compare
This way we are making sure that the integration tests infra doesn't regress on musl environments.
vadorovsky
force-pushed
the
integration-tests-linker
branch
2 times, most recently
from
8175be3
to
ae94156
Compare
The recommendation (coming from rust-lang/rust#130062) for Linux hosts
is using C compiler driver as a linker, which is able to find
system-wide libraries. Using linker binaries directly in
-C linker(e.g.
-C linker=rust-lld) often results in errors like:Not touching the linker settings is usually the best approach for Linux
systems. Native builds pick up the default C toolchain. Cross builds
default to GCC cross wrapper, but that's easy to supress with clang
and lld using RUSTFLAGS.
However,
-C linker=rust-lldstill works the best on macOS, whereRust toolchains come with unwinder and runtime and there is usually no
need to link system libraries. Keep setting it only for macOS.
Fixes #907