marvin-hansen
commented
2 months ago ah yea, just ran into this issue.
Full replication: https://github.com/marvin-hansen/musl_cross_compiling
Basically, on linux-gnu, instead of the MUSL toolchain, the Clang toolchain gets selected.
As a result, the binary will be dynamically linked.
ARM (aarch64) on Linux is fine, and Apple is fine for any combination. It's just x86_64_musl that breaks on Gnu Linux
This affects me currently because my CI runs on Linux and builds the dynamically linked binaries.
Filled another issue with more details: https://github.com/bazelbuild/rules_rust/issues/2726
The musl_cross_compiling example doesn't work out of the box when compiling on linux-gnu for linux-musl.
In that case, we need two rust toolchains - one for our exec tools which compiles linux-gnu -> linux gnu, and another for our target output which compiles linux-gnu -> linux-musl. When doing a build currently, the correct C++ toolchain is chosen in each case, but the linux-gnu -> linux-gnu Rust toolchain is selected for both target platforms. This is incorrect - the linux-gnu -> linux-gnu toolchain should not be selected for linux-gnu -> linux-musl because it has a constraint it doesn't satisfy.
I believe this is because in a few places we hard-code an assumption basically that "any Linux toolchain is good enough for any Linux target".
One of these places is here: https://github.com/bazelbuild/rules_rust/blob/8b977b5f7020fc3a3b3bbc318e414269014f126a/rust/repositories.bzl#L984-L988
where we prevent users from telling us "this toolchain actually has a more specific target platform than you expect" - we should swap the order of these
if-branches.Another is here: https://github.com/bazelbuild/rules_rust/blob/8b977b5f7020fc3a3b3bbc318e414269014f126a/rust/repositories.bzl#L870
where we encode an assumption that every toolchain is appropriate for targeting its own exec triple.
Fixing these two is sufficient for building example that depends on libc.
See https://github.com/illicitonion/rules_rust/commits/musl-from-linux/ for an example of making this work - the top commit does some hacky changes to break these assumptions, but someone who knows more about the toolchain set-up and/or has more time to think about the consequences of these changes should work out what the best real fix for these problems is.
cc @matte1