| 29 Sep 2025 |
matthewcroughan | For example
t4204-patch-id.sh .................................. Dubious, test returned 1 (wstat 256, 0x100)
Failed 1/26 subtests
| 13:07:57 |
Alyssa Ross | It happens on x86_64 glibc too | 13:09:22 |
Alyssa Ross | At least some git tests are flaky | 13:09:34 |
matthewcroughan | Oh right so just a general failure | 13:09:38 |
matthewcroughan | I didn't check that actually yeah | 13:09:45 |
matthewcroughan | I'm making flakes with CI right now to track some of this stuff | 13:09:57 |
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 |