Rust Cross-Compiler doesn't build

[elitak]

I'm out of things to try to get a working rustc+cargo that can cross-compile to mingw32 or mingwW64. Not even arm7l-hf works, which is more straightforward, in terms of building up the toolchain.

It should be as simple as using any of these to get a working cross-compiler:

    nix-build -A pkgsCross.armv7l-hf-multiplatform.cargo
    nix-build -A pkgsCross.mingw32.cargo
    nix-build -A pkgsCross.mingwW64.cargo

I believe this is probably broken in many places along the toolchain, from mingw32 trying to compile libc-dependent libs, to rustc's source code needing patches to get the target triplet interpreted correctly. The rustc package function was reworked some time ago to accept pkgsBuild{Build,Host,Target}, but I've had no success in using them and can't see how they ever worked to produce a cross-compiler.

@dvc94ch might know? I used some patches he submitted some years ago to get something working back on the old master branch.

I can add more detail about the specific failures, but I wanted to first check if anybody knew something I didn't about getting cross-compiling Rust working.

Metadata

• system: "x86_64-linux"
• host os: Linux 4.19.66, NixOS, 19.09.git.b1ef79196c2 (Loris)
• multi-user?: yes
• sandbox: yes
• version: nix-env (Nix) 2.2.2
• nixpkgs: 893b50a

[matthewbauer]

I'm not sure how cargo works, but are you sure you can't just use the native cargo here? I think it should just let you specify a custom rustc. Otherwise I don't think you want to run Cargo on your target system.

These should be working though:

    nix-build -A pkgsCross.armv7l-hf-multiplatform.buildPackages.rustc
    nix-build -A pkgsCross.mingw32.buildPackages.rustc
    nix-build -A pkgsCross.mingwW64.buildPackages.rustc

[elitak]

I forgot about needing to use cargo.override { rustc = pkgsCross.armv7l-hf-multiplatform.buildPackages.rustc; } and the .buildPackages part, thanks. Armv7 builds rust, after target-triplet patches to the Rust src, but won't compile my test project--something about incorrect link format. Mingw ones are hopelessly stuck when they hit one of the librust_ components that has #include <link.h> in it, so I need another Rust patch to advance on that one.

here's the error for armv7:

/nix/store/cl1i6bfqnx48ipakj4px7pb1babzs23j-binutils-2.31.1/bin/ld: /tmp/rs-hello/target/armv7l-unknown-linux-gnueabihf/debug/deps/rs_hello-34ab505f86b8d35f.2r3hkdvfozm
517kt.rcgu.o: relocations in generic ELF (EM: 40)
          /nix/store/cl1i6bfqnx48ipakj4px7pb1babzs23j-binutils-2.31.1/bin/ld: /tmp/rs-hello/target/armv7l-unknown-linux-gnueabihf/debug/deps/rs_hello-34ab505f86b8d35f.2r3hkdvfozm
517kt.rcgu.o: error adding symbols: file in wrong format
          collect2: error: ld returned 1 exit status

I can create a demo project repo to reproduce the problems. Thanks for the tips so far.

[piegamesde]

Ping @yegortimoshenko

[lukateras]

I didn't have much luck with natively built cross-compiling rustcs, but cross-compilation using prebuilt toolchains available in nixpkgs-mozilla has been working great for me, with Linux aarch64 and even Windows x86_64 as targets: https://github.com/Holo-Host/holo-nixpkgs/blob/a26629037ea6ef966fb5c0594b5d501003fbbb55/overlays/holo-nixpkgs/default.nix#L268-L287

[piegamesde]

@yegortimoshenko Thank you, this works. In case anyone else is interested, this got me started:

let
  moz_overlay = import (builtins.fetchTarball https://github.com/mozilla/nixpkgs-mozilla/archive/master.tar.gz);
  nixpkgs = import <nixpkgs> { overlays = [ moz_overlay ]; };
in
  with nixpkgs;
  stdenv.mkDerivation {
    name = "moz_overlay_shell";
    buildInputs = [
      (nixpkgs.latest.rustChannels.nightly.rust.override {
          targets = [
            "armv7-unknown-linux-gnueabihf"
          ];
      })
    ];
  }

[stale]

Hello, I'm a bot and I thank you in the name of the community for opening this issue.

To help our human contributors focus on the most-relevant reports, I check up on old issues to see if they're still relevant. This issue has had no activity for 180 days, and so I marked it as stale, but you can rest assured it will never be closed by a non-human.

The community would appreciate your effort in checking if the issue is still valid. If it isn't, please close it.

If the issue persists, and you'd like to remove the stale label, you simply need to leave a comment. Your comment can be as simple as "still important to me". If you'd like it to get more attention, you can ask for help by searching for maintainers and people that previously touched related code and @ mention them in a comment. You can use Git blame or GitHub's web interface on the relevant files to find them.

Lastly, you can always ask for help at our Discourse Forum or at #nixos' IRC channel.

[patka-123]

Hello @elitak 👋

I'm wondering if this is still an issue or if it has been resolved by now. I think it is, but I'm not fully confident. If it is, would you able to close this issue?

(I'm going through issues marked as stale to see what can be resolved. If this is still an issue then don't mind me.)