Rust build for different target

Development
1

Hi,

I’m trying to see how feasible it is to build my rust package statically by using the musl target.
As I’m playing with this I’ve noticed that on later versions of nixpkgs seem to specify a different target on the cargo build. A very simple example:

with (import <nixpkgs> {});

rustPlatform.buildRustPackage {
  name = "musl";
  src = ./musl;
  cargoSha256 = "052gm8cxlk72ph30kggmp8456kdki2s6sjk8ayqfrxkzdsqz5mmy";
  target = "x86_64-unknown-linux-musl";
}

With with (import <nixpkgs> {}); I see:
nix-build .
…
cargo build -j 16 --release --target x86_64-unknown-linux-musl

With with (import <nixpkgs-unstable> {}); I see:
nix-build .
…
cargo build -j 16 --target x86_64-unknown-linux-gnu

Is this expected or am I missing something (most likely the latter)?

Thank you!

2

Ah, it seems that this: commit has removed the target option…
Does that mean we can no longer use of GitHub - oxalica/rust-overlay: Pure and reproducible nix overlay of binary distributed rust toolchains to provide the " x86_64-unknown-linux-musl target and we have to cross compile which takes forever?

3

Even if the target attribute was removed, I don’t see why that would prevent one from sourcing the Rust toolchain using oxalica’s overlay or fenix.

I am curious about cross compiling a Rust binary to musl using flakes.
From what I read, many blog articles reference an opinionated alternative called naersk. You might find the cross compiling example helpful.

From that example, you could try declaring the environment variable CARGO_BUILD_TARGET.

4

Thanks for the suggestion, naersk works a charm!

I think the reason it doesn’t work for buildRustPackage is because the overlay only replaces the rustc and cargo, and so the stdenv is still set to what is was previously, and the hostPlatform ends up being used, which is not the one we wanted here.

1 Like
5

Ah, thanks for the explanation. Good to know about the way buildRustPackage interacts with community Rust overlays. That makes sense to me!