| 29 Sep 2025 |
matthewcroughan | yeah it just looks like flakiness | 13:10:53 |
matthewcroughan | maybe that can somehow be reduced by reducing parallelism | 13:11:00 |
matthewcroughan | error: Cannot build '/nix/store/n5bnwbw7wh2l4bk6y7arl70fghgk2ri7-python3.13-fb-re2-1.0.7.drv'.
Reason: builder failed with exit code 1.
Output paths:
/nix/store/2sc10vh6wjylr4nk8rd9kylglg0i6nsd-python3.13-fb-re2-1.0.7
/nix/store/gphgdcysf9yv6sliimd8hqb6p20vr812-python3.13-fb-re2-1.0.7-dist
Last 25 log lines:
> running bdist_wheel
> running build
> running build_py
> creating build/lib.linux-aarch64-cpython-313
> copying re2.py -> build/lib.linux-aarch64-cpython-313
> running build_ext
> building '_re2' extension
> creating build/temp.linux-aarch64-cpython-313
> g++ -fno-strict-overflow -Wsign-compare -DNDEBUG -g -O3 -Wall -fPIC -I/nix/store/b187n72n9xglqyypj0f9nyhm9xhi3abz-python3-3.13.7/include/python3.13 -c _re2.cc -o build/temp.linux-aarch64-cpython-313/_re2.o -std=c++17
> _re2.cc:252:1: error: cannot convert ‘std::nullptr_t’ to ‘Py_ssize_t’ {aka ‘long int’} in initialization
> 252 | };
> | ^
> _re2.cc:296:1: error: cannot convert ‘std::nullptr_t’ to ‘Py_ssize_t’ {aka ‘long int’} in initialization
> 296 | };
> | ^
> _re2.cc:340:1: error: cannot convert ‘std::nullptr_t’ to ‘Py_ssize_t’ {aka ‘long int’} in initialization
> 340 | };
> | ^
| 13:56:26 |
matthewcroughan | new issue | 13:56:28 |
| jeremy joined the room. | 20:44:23 |
| Lun joined the room. | 20:55:30 |
| 30 Sep 2025 |
| Niklas Förster changed their display name from Niklas Förster (vacation until 29.09.) to Niklas Förster. | 07:50:15 |
| 17lifers (at mikuplushfarm) joined the room. | 16:05:09 |
| 17lifers (at mikuplushfarm) | 16:06:50 |
| 17lifers (at mikuplushfarm) left the room. | 18:24:05 |
| 1 Oct 2025 |
| Qyriad left the room. | 12:22:18 |
| Theodora The Absurdist Schizotisticoball joined the room. | 13:48:42 |
| 2 Oct 2025 |
spikespaz | are there any good examples of cross compiling a windows dylib using rust-overlay, but no naersk, no crane, and no fenix? I could read through their source to see how they work, but that's a lot of effort. I tried writing the derivation as trivially as possible, but pkgs.pkgsCross.mingw32.callPackage'd it, and it didn't work. Then I tried setting environment variables, also doesn't work. I think I need to be more granular choosing dependencies from buildPackages, but I'm not sure what that looks like. Any vetted resources appreciated. | 21:05:53 |
rosssmyth | 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 | it's a 32 bit dylib for a game. | 21:18:20 |
rosssmyth | 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 | 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 | why are you using the buildPackages pkgset? That will for sure do the wrong thing. | 21:20:43 |
rosssmyth | Just use the rustPlatform that you get from callPackage | 21:21:40 |
rosssmyth | Or no, sorry I confused it with pkgsBuildBuild. But still it is strange to do | 21:22:47 |
spikespaz | 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 | 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 | So yes it must be in pkgsBuildHost, but it will be regardless | 21:27:11 |
rosssmyth | As that is what the rustPlatform pkgset does | 21:27:26 |
rosssmyth | Anyways, you don't show how you build the rustPlatform | 21:28:06 |
spikespaz | 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 | That is exactly what you want | 21:29:51 |
rosssmyth | Unless you use rustc from rust-overlay | 21:30:07 |
rosssmyth | In which case you can just tell it to do the right thing | 21:30:42 |
spikespaz | Doesn't that require a binfmt translator to run the windows-native rustc? | 21:31:09 |