| 2 Oct 2025 |
@rosssmyth:matrix.org | What is your "trival" derivation? I cross to mingw at work for one project. I'd recommend crossing to mingwW64 is you are targeting x86_64 fwiw | 21:17:46 |
@spikespaz:envs.net | it's a 32 bit dylib for a game. | 21:18:20 |
@rosssmyth:matrix.org | Here's an example that is pretty close to what I do: https://github.com/RossSmyth/rustNixExample/blob/rustTemplate/flake.nix | 21:18:47 |
@spikespaz:envs.net | I'll look at that. As for the prototype, I've tried a bunch of things, but here's where I left off yesterday.
{ sourceRoot, lib, pkgsCross, makeRustPlatform }:
pkgsCross.mingw32.callPackage
({ rustPlatform, buildPackages, pkg-config, cmake, wine }:
buildPackages.rustPlatform.buildRustPackage (finalAttrs:
let
inherit (finalAttrs) src pname version meta buildInputs;
manifest = lib.importTOML "${src}/ewext/Cargo.toml";
in {
pname = "ewext";
inherit (manifest.package) version;
src = sourceRoot;
sourceRoot = "source/ewext";
cargoLock.lockFile = "${src}/ewext/Cargo.lock";
# cargoBuildTarget = "i686-pc-windows-gnu";
strictDeps = true;
nativeBuildInputs = [ pkg-config cmake ];
nativeCheckInputs = [ wine ];
doCheck = false;
# buildInputs = with pkgsCross.mingw32; [ openssl ];
env = { CARGO_TARGET_I686_PC_WINDOWS_GNU_RUNNER = "wine"; };
# env = {
# # CARGO_TARGET_I686_PC_WINDOWS_GNU_LINKER = "${mingw32.stdenv.cc.targetPrefix}gcc";
# OPENSSL_DIR = "${lib.getDev pkgsCross.mingw32.openssl}";
# OPENSSL_LIB_DIR = "${lib.getLib pkgsCross.mingw32.openssl}/lib";
# OPENSSL_NO_VENDOR = 1;
# };
meta = { };
})) { }
| 21:19:52 |
@rosssmyth:matrix.org | why are you using the buildPackages pkgset? That will for sure do the wrong thing. | 21:20:43 |
@rosssmyth:matrix.org | Just use the rustPlatform that you get from callPackage | 21:21:40 |
@rosssmyth:matrix.org | Or no, sorry I confused it with pkgsBuildBuild. But still it is strange to do | 21:22:47 |
@spikespaz:envs.net | Because if you override the rustPlatform from outside, that technically belongs in buildPackages anyway, since it's build->target not host->target. So I got rustPlatform from buildPackages to avoid building i686-pc-windows-gnu-rustc | 21:24:03 |
@rosssmyth:matrix.org | There is no target here, you are not building a compiler. You need a rustc that is build->host, so it must come from pkgsBuildHost, which buildPackages is an alias for. | 21:26:44 |
@rosssmyth:matrix.org | So yes it must be in pkgsBuildHost, but it will be regardless | 21:27:11 |
@rosssmyth:matrix.org | As that is what the rustPlatform pkgset does | 21:27:26 |
@rosssmyth:matrix.org | Anyways, you don't show how you build the rustPlatform | 21:28:06 |
@spikespaz:envs.net | so if I use rustPlatform from the package input, it starts to compile i686-pc-windows-gnu-rustc and friends, I don't think that's what we want. | 21:29:31 |
@rosssmyth:matrix.org | That is exactly what you want | 21:29:51 |
@rosssmyth:matrix.org | Unless you use rustc from rust-overlay | 21:30:07 |
@rosssmyth:matrix.org | In which case you can just tell it to do the right thing | 21:30:42 |
@spikespaz:envs.net | Doesn't that require a binfmt translator to run the windows-native rustc? | 21:31:09 |
@rosssmyth:matrix.org | That is not what it is compiling. | 21:31:28 |
@rosssmyth:matrix.org | It is basically compiling rustc that can target x86 | 21:31:38 |
@rosssmyth:matrix.org | But because of limitation of the rustc derivation it must rebuild all of rustc | 21:31:51 |
@spikespaz:envs.net | How does this look to you? This is very much in flux, and the outer rustPlatform from rust-overlay is unused at the moment. That is on purpose; I'd like to get it working with nixpkgs#rustPlatform. https://github.com/spikespaz-contrib/noita-entangled-worlds/blob/u/jacob/nix-package-ewext/nix/packages/ewext.nix | 21:32:15 |
@rosssmyth:matrix.org | It is target-prefixed like gcc | 21:32:05 |
@rosssmyth:matrix.org | targets is a list | 21:32:51 |
@spikespaz:envs.net | it's not being used anyway at the moment. | 21:33:15 |
@rosssmyth:matrix.org | Looks fine to me. Why aren't you using it? | 21:34:02 |
@spikespaz:envs.net | > /nix/store/asqlz348q8ln81iza5wv79wvrrqhfvxh-i686-w64-mingw32-binutils-2.44/bin/i686-w64-mingw32-ld: /build/rustc-1.89.0-src/build/x86_64-unknown-linux-gnu/stage1-std/i686-pc-windows-gnu/release/deps/libgimli-10feed5729a3b158.rlib(gimli-10feed5729a3b158.gimli.3fc3ea03a1049962-cgu.01.rcgu.o):gimli.3fc3ea03a1049962-cgu.01:(.text+0xa6): more undefined references to `_Unwind_Resume' follow
> collect2: error: ld returned 1 exit status
>
> = note: some `extern` functions couldn't be found; some native libraries may need to be installed or have their path specified
> = note: use the `-l` flag to specify native libraries to link
> = note: use the `cargo:rustc-link-lib` directive to specify the native libraries to link with Cargo (see https://doc.rust-lang.org/cargo/reference/build-scripts.html#rustc-link-lib)
>
> error: could not compile `std` (lib) due to 1 previous error
| 21:34:10 |
@spikespaz:envs.net | as stated, I want to shim in rust-bin at the last possible moment. | 21:34:28 |
@rosssmyth:matrix.org | What's the last possible moment? I don't understand the goal | 21:34:51 |
@rosssmyth:matrix.org | Just provide it as an input to the derivation | 21:35:33 |
@spikespaz:envs.net | The goal is to get the build working without rust-bin for now | 21:35:50 |