Cross-compilation with MinGW broken

[abbec]

Hi,

c7ed82b broke our cross-compilation for Windows. It seems that with this change, buildInputs (i.e. depsHostTarget) end up in the linker for the build platform (i.e. Linux) which results in /nix/store/5ddb4j8z84p6sjphr0kh6cbq5jd12ncs-binutils-2.35.1/bin/ld: /nix/store/pl9raxwyb6jg662ljd9f1q3hrb2cni8l-pthreads-w32-x86_64-w64-mingw32-2.9.1/lib/libpthread.a: error adding symbols: file format not recognized.

The commit before c7ed82b works as expected.

NIX_LDFLAGS and NIX_LDFLAGS_FOR_BUILD looks the same in both a working and non-working case though?

[abbec]

It looks like the same problem discussed at the end of #52, and it did work before c7ed82b so I think the issue is in here, or it exposed an issue in Nixpkgs.

[abbec]

Actually there is a small difference in *_LDFLAGS:

Working:

❯ echo $NIX_LDFLAGS
-L/nix/store/14s60q99gfkm52rfzfxry60cnm1f463j-mcfgthreads-x86_64-w64-mingw32-git/lib -L/nix/store/pl9raxwyb6jg662ljd9f1q3hrb2cni8l-pthreads-w32-x86_64-w64-mingw32-2.9.1/lib

❯ echo $NIX_LDFLAGS_FOR_BUILD
-L/nix/store/6bsh70027xrmjsqjxn5wpmwcl2xq8mg0-rust-default-1.53.0/lib -L/nix/store/2jh1myphkbxwwnw9zry684lybg3skgs4-file-5.39/lib

Not working:

❯ echo $NIX_LDFLAGS
-L/nix/store/14s60q99gfkm52rfzfxry60cnm1f463j-mcfgthreads-x86_64-w64-mingw32-git/lib -L/nix/store/14s60q99gfkm52rfzfxry60cnm1f463j-mcfgthreads-x86_64-w64-mingw32-git/lib -L/nix/store/pl9raxwyb6jg662ljd9f1q3hrb2cni8l-pthreads-w32-x86_64-w64-mingw32-2.9.1/lib -L/nix/store/pl9raxwyb6jg662ljd9f1q3hrb2cni8l-pthreads-w32-x86_64-w64-mingw32-2.9.1/lib

❯ echo $NIX_LDFLAGS_FOR_BUILD
-L/nix/store/q25xrjk7sq5pfqnr50xbmkrrkdab2nj1-rust-default-1.53.0/lib -L/nix/store/2jh1myphkbxwwnw9zry684lybg3skgs4-file-5.39/lib

So it is added twice in the case it does not work? Setting it to the "working version" seems to do nothing though.

[abbec]

AH!

There is a difference (that also makes sense):

Working:

❯ cat /nix/store/6bsh70027xrmjsqjxn5wpmwcl2xq8mg0-rust-default-1.53.0/nix-support/propagated-build-inputs
(empty)

❯ cat /nix/store/6bsh70027xrmjsqjxn5wpmwcl2xq8mg0-rust-default-1.53.0/nix-support/propagated-native-build-inputs
/nix/store/88ghxafjpqp5sqpd75r51qqg4q5d95ss-gcc-wrapper-10.3.0 /nix/store/88ghxafjpqp5sqpd75r51qqg4q5d95ss-gcc-wrapper-10.3.0

Not working:

❯ cat /nix/store/q25xrjk7sq5pfqnr50xbmkrrkdab2nj1-rust-default-1.53.0/nix-support/propagated-build-inputs
/nix/store/88ghxafjpqp5sqpd75r51qqg4q5d95ss-gcc-wrapper-10.3.0 /nix/store/88ghxafjpqp5sqpd75r51qqg4q5d95ss-gcc-wrapper-10.3.0

❯ ls /nix/store/q25xrjk7sq5pfqnr50xbmkrrkdab2nj1-rust-default-1.53.0/nix-support/
propagated-build-inputs
(no propagated-native-build-inputs)

Is it really expected that a derivation using the Rust compiler gets the host platform compiler as a buildInput (runtime dependency)? A nativeBuildInput makes sense though.

[abbec]

Note also that you will only be able to repro this error when you have a build.rs.

[abbec]

I have created an example+repro case in #60. Feel free to only use it to reproduce the issue or keep it as a permanent example/test :) I also added a CI job that fails with this exact error.

[abbec]

Commenting out propagatedBuildInputs on

rust-overlay/rust-overlay.nix

Line 208 in 885ef5b

propagatedBuildInputs =

, and instead adding depsBuildBuild = [ buildPackages.stdenv.cc ] in my derivation fixes both this issue and #54 (!?).

[oxalica]

Commenting out propagatedBuildInputs on

rust-overlay/rust-overlay.nix

Line 208 in 885ef5b

propagatedBuildInputs =

, and instead adding depsBuildBuild = [ buildPackages.stdenv.cc ] in my derivation fixes both this issue and #54 (!?).

I use propagatedBuildInputs at first time because I want to add gcc to both downstream depsBuildBuild (for build script linking) and nativeBuildInputs (for crate linking). You reminds me that the former should actually be depsHostHostPropagated on our side. But the latter one is surely propagatedBuildInputs.

Here the issue is that CC wrapper for build script thinks it's from nativeBuildInputs and add NIX_LDFLAGS instead of NIX_LDFLAGS_FOR_BUILD, thus trying to link wrong libraries.
I'm working on this.

[abbec]

Thank you! Yeah, this seems like more of a nixpkgs bug?

[oxalica]

Found that I stdenv.cc is always brought from buildPackages so pkgsHostTarget.stdenv.cc actually equals pkgsBuildHost.gcc, thus I used to pull in wrong ccs.

Now it's fixed.