Nix Cross Compiling | 579 Members | |
| 126 Servers |
| Sender | Message | Time |
|---|---|---|
| 23 Feb 2025 | ||
| that's, uh, wow | 04:02:04 | |
| If testing is needed, I can test on Ampere lol. | 04:10:23 | |
| 24 Feb 2025 | ||
| Is there a non-zero chance of being able to build a python app using pkgsCross.mingwW64? I'm running into issues early on with bash complaining it can't run as a pe executable (seems totally reasonable, but I'm not sure where it's decided it needs to do that) Or alternatively, any chance of being able to build python things for windows in some form of VM/wine/something | 05:30:23 | |
In reply to @axman6:matrix.orgUsing Python 3.11, maybe. I think at least the interpreter built successfully, not sure about most packages.. | 06:38:26 | |
| 25 Feb 2025 | ||
When using callPackage ./whatever {rustPlatform = customPlatform}, are the rust and cargo packages spliced into the package the same that are under rustPlatform.rust.{rustc, cargo}? | 21:00:04 | |
| You have to add customPlatform toplevel to have it spliced | 21:01:26 | |
| Amd then rustPlatform = __splicedPackages.customPlatform | 21:01:41 | |
| * You have to add customPlatform toplevel or available from thereto have it spliced | 21:02:55 | |
| I'm sorry, I'm not quite sure what you mean. I currently have a file that is like
Which is called from another file with a rust-overlay toolchain using
as it keeps yelling at me that using | 21:09:13 | |
| Ok, the answer is no you cannot do that. | 21:18:23 | |
[rust, cargo] is invalid syntax | 21:27:54 | |
[rustc cargo] should work. but you probably want rustPlatform.cargo{Setup,Build}Hook? and you probably even just want rustPlatform.buildRustPackage | 21:28:55 | |
| yeah sorry | 21:31:40 | |
| I had it as rustc | 21:31:44 | |
| but I looked at nix-diff and it pulls in the incorrect rustc and cargo | 21:32:01 | |
| Your rustPlatform override only affects that attr | 21:32:35 | |
is there a reason you're not just using rustPlatform.buildRustPackage? | 21:32:40 | |
| I do use the hooks, but you must supply rustc and cargo in the build inputs otherwise it fails to build. | 21:33:04 | |
right. but I mean if you're just building a simple Rust package you don't need to explicitly specify any of that with buildRustPackage. (if it's more elaborate then carry on) | 21:33:45 | |
| And I am not using buildRustPackage because my snippet isn't exactly what I have written. I am using finalAttrs a lot which is not compatible with buildRustPackage (yet) | 21:33:54 | |
| Once either #354999 or #194475 are merged I shall switch to buildRustPackage | 21:34:58 | |
| In the past month, a rust cross build in my CI broke: https://github.com/NixOS/nixpkgs/issues/384662. I don't have a lot of rust experience, but experimenting in Any help would be much appreciated :D | 23:55:13 | |
| it could be caused by something up stream, but haven't been able to verify | 23:56:14 | |
| 26 Feb 2025 | ||
| maybe related to https://github.com/NixOS/nixpkgs/pull/369424 | 00:09:05 | |
This is more a style thing than anything I guess, but if you're developing a project which is intended to build cross compiled packages (using flakes), would you add those a individual packages and use nix build .#foo-aarch64-linux or would you use legacyPackages and use nix build .#legacyPackages.pkgsCross.aarch64-multiplatform.foo? I have a flake which currently does the former, and I need the binaries it produces for specific platforms in another flake, and it feels a bit weird sometimes using packages.bar = pkgs.foo; and sometimes using packages.bar-platform = pkgs.bar.override {foo = foo-flake.packages.${system}.foo-platform;}; (where foo-platform was defined as packages.foo-platform = pkgs.pkgsCross.platform.foo;) | 01:46:40 | |
| emily: thanks that is indeed the cause | 02:23:43 | |
| I suggest leaving a comment :) | 02:24:27 | |
| yep! https://github.com/NixOS/nixpkgs/pull/369424#issuecomment-2683739473 | 02:31:13 | |
| provide an overlay | 14:48:12 | |
| 18:20:26 | ||