Wrong platform triplet for x86_64-pc-windows-gnu(x86_64-w64-mingw32)

[gjz010]

cargo2nix generates dependency platform target expression using LLVM triplet, while Nix compares the triplet with hostPlatform.config directly.

Example:

${ if hostPlatform.config == "x86_64-pc-windows-gnu" then "winapi_x86_64_pc_windows_gnu" else null } = (rustPackages."registry+https://github.com/rust-lang/crates.io-index".winapi-x86_64-pc-windows-gnu."0.4.0" { inherit profileName; }).out;

An ad-hoc patch below solves the problem for mingw-w64 temporarily, but I doubt a better way is to use the translation overriding mechanism introduced by commit e87411f .

diff --git a/src/platform.rs b/src/platform.rs
--- a/src/platform.rs
+++ b/src/platform.rs
@@ -5,6 +5,9 @@ use crate::expr::BoolExpr;
 pub fn to_expr(p: &Platform, platform_var: &str) -> BoolExpr {
     match p {
         Platform::Name(triplet) => {
+            if &format!("{}", triplet) == "x86_64-pc-windows-gnu"{
+                return BoolExpr::Single(format!("{}.config == {:?}", platform_var, "x86_64-w64-mingw32"))
+            }
             BoolExpr::Single(format!("{}.config == {:?}", platform_var, triplet))
         }
         Platform::Cfg(cfg) => cfg_to_expr(cfg, platform_var),

[psionic-k]

Neat. Probably nobody was using it. If you get it working, can you PR a fix? There's only one or two files that do this transformation.

Some of the fixes were supposed to be upstreamed to nixpkgs a while back, but it's fine to only fix it in cargo2nix.

[gjz010]

In fact there are two extra problems with cross-compiling to mingw-w64:

• While nixpkgs has switched to a default mcfgthread-based cross toolchain, rustc still wants to link to pthread, which would cause an linking error.
  • This indeed should be an Rust upstream fix.
  • Trying to fix this at cargo2nix causes rebuild of std crate, which cargo2nix is currently incapable of.
  • Fortunately, while mcfgthread in nixpkgs is just dynamically linked by libgcc_s_seh.dll, an empty libpthread.a is enough as a workaround (i.e. without needing to rebuild std).
    • Pre-gcc13 mcfgthread cannot be linked statically.
    • Post-gcc13 mcfgthread is upstreamed to gcc and can be linked statically, but static build of mcfgthread is by default disabled by nixpkgs.

[gjz010@nixos-desktop:~/playground]$ nix-shell -p "(pkgs.overrideCC pkgs.pkgsCross.mingwW64.stdenv pkgsCross.mingwW64.buildPackages.gcc13).cc"
[nix-shell:~/playground]$ x86_64-w64-mingw32-g++ ht.cpp  -static
/nix/store/w7339132hmzlmw63d7h7wm1ls23dcz8f-x86_64-w64-mingw32-binutils-2.40/bin/x86_64-w64-mingw32-ld: cannot find -lmcfgthread: No such file or directory
/nix/store/w7339132hmzlmw63d7h7wm1ls23dcz8f-x86_64-w64-mingw32-binutils-2.40/bin/x86_64-w64-mingw32-ld: cannot find -lmcfgthread: No such file or directory
collect2: error: ld returned 1 exit status

• Both winapi and windows-rs ships some IMPLIBs in CARGO_MANIFEST_DIR (pointing to /build in cargo2nix), which needs to be copied to output dir.
  • This can be fixed by adding an overlay around them.

I will try to write a pull request to cover them all recently.