Nix Cross Compiling | 532 Members | |
| 109 Servers |
| Sender | Message | Time |
|---|---|---|
| 2 Oct 2025 | ||
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 | |
| 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 | |
| it's a 32 bit dylib for a game. | 21:18:20 | |
| Here's an example that is pretty close to what I do: https://github.com/RossSmyth/rustNixExample/blob/rustTemplate/flake.nix | 21:18:47 | |
| I'll look at that. As for the prototype, I've tried a bunch of things, but here's where I left off yesterday.
| 21:19:52 | |
why are you using the buildPackages pkgset? That will for sure do the wrong thing. | 21:20:43 | |
Just use the rustPlatform that you get from callPackage | 21:21:40 | |
| Or no, sorry I confused it with pkgsBuildBuild. But still it is strange to do | 21:22:47 | |
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 | |
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 | |
| So yes it must be in pkgsBuildHost, but it will be regardless | 21:27:11 | |
| As that is what the rustPlatform pkgset does | 21:27:26 | |
| Anyways, you don't show how you build the rustPlatform | 21:28:06 | |
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 | |
| That is exactly what you want | 21:29:51 | |
| Unless you use rustc from rust-overlay | 21:30:07 | |
| In which case you can just tell it to do the right thing | 21:30:42 | |
| Doesn't that require a binfmt translator to run the windows-native rustc? | 21:31:09 | |
| That is not what it is compiling. | 21:31:28 | |
| It is basically compiling rustc that can target x86 | 21:31:38 | |
| But because of limitation of the rustc derivation it must rebuild all of rustc | 21:31:51 | |
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 | |
| It is target-prefixed like gcc | 21:32:05 | |
| targets is a list | 21:32:51 | |
| it's not being used anyway at the moment. | 21:33:15 | |
| Looks fine to me. Why aren't you using it? | 21:34:02 | |
| 21:34:10 | |
as stated, I want to shim in rust-bin at the last possible moment. | 21:34:28 | |
| What's the last possible moment? I don't understand the goal | 21:34:51 | |
| Just provide it as an input to the derivation | 21:35:33 | |