!ayCRiZriCVtuCUpeLp:nixos.org

Nix Cross Compiling

580 Members
128 Servers

Load older messages


SenderMessageTime
7 Feb 2025
@kranzes:matrix.orgIlan Joselevich (Kranzes)
In reply to @kranzes:matrix.org
Don't bother with buildRustCrate and crate2nix
I think they're doomed
00:06:00
@kranzes:matrix.orgIlan Joselevich (Kranzes)Crane maybe fine because it's still cargo00:06:11
@kranzes:matrix.orgIlan Joselevich (Kranzes) But reimplementing cargo in Nix is miserable 00:06:31
@kranzes:matrix.orgIlan Joselevich (Kranzes) Way too much work and practically impossible to get right 00:06:48
@kranzes:matrix.orgIlan Joselevich (Kranzes)Anyway, figure out how to do that cross compilation with rustPlatform00:08:45
@mindtree:matrix.orgmindtreeGot this working! Posted a small tutorial on the forum thread: https://discourse.nixos.org/t/building-a-rust-package-derivation-using-buildrustpackage-for-wasm32-unknown-unknown/59925/2?u=mindtree01:05:39
@thing-han:matrix.orgLim, Thing-han joined the room.03:34:18
@terrorjack:matrix.terrorjack.comterrorjack left the room.22:28:01
@diamondburned:matrix.orgdiamond (it/its) changed their profile picture.23:10:50
@diamondburned:matrix.orgdiamond (it/its) changed their profile picture.23:18:50
@diamondburned:matrix.orgdiamond (it/its) changed their profile picture.23:19:57
8 Feb 2025
@terrorjack:matrix.orgterrorjack joined the room.01:18:22
@terrorjack:matrix.orgterrorjack set a profile picture.02:24:24
@terrorjack:matrix.orgterrorjack removed their profile picture.02:25:00
@mindtree:matrix.orgmindtree

Update: while the above^ works on aarch64-darwin as the build machine, I'm now running into issues when using x86_64-linux as the build machine.

It looks like even when just building a hello-world rust program with rustPlatform.buildrustPackage via pkgs.pkgsCross.wasm32-unknown-none.callPackage, it starts compiling LLVM and then rustc from scratch.

This was kind of expected after my experience on my mac, where the same happened, however on the mac they at least complete successfully after an hour or two. On my linux build machine, rustc fails to build during the bootstrap phase with a libunwind .so not found error.

Shouldn't llvm and rustc be cached for the pkgsCross.wasm32-unknown-none? Perhaps they're not, because there are no packages that actually use pkgsCross.wasm32-unknown-none, so as a result hydra never builds and caches them?

If so, what would be the best way to get hydra testing and building these? Would I need to add some simple hello-world-rust-wasm32-unknown-none package to pkgs/by-name/he/ or something along these lines?

I guess working out why rustc won't build is another issue, but at least with some basic package

Also, another thing I'm noticing is that regardless of what I put in meta.platforms, it always says the system is unsupported when building with pkgsCross.wasm32-unknown-none, and I always have to add NIXPKGS_ALLOW_UNSUPPORTED_SYSTEM=1 and --impure everytime I build 🫠 I might look into addressing this too.

12:34:22
@mindtree:matrix.orgmindtree *

Update: while the above^ works on aarch64-darwin as the build machine, I'm now running into issues when using x86_64-linux as the build machine.

It looks like even when just building a hello-world rust program with rustPlatform.buildrustPackage via pkgs.pkgsCross.wasm32-unknown-none.callPackage, it starts compiling LLVM and then rustc from scratch.

This was kind of expected after my experience on my mac, where the same happened, however on the mac they at least complete successfully after an hour or two. On my linux build machine, rustc fails to build during the bootstrap phase with a libunwind .so not found error.

Shouldn't llvm and rustc be cached for the pkgsCross.wasm32-unknown-none? Perhaps they're not, because there are no packages that actually use pkgsCross.wasm32-unknown-none, so as a result hydra never builds and caches them?

If so, what would be the best way to get hydra testing and building these? Would I need to add some simple hello-world-rust-wasm32-unknown-none package to pkgs/by-name/he/ or something along these lines?

I guess working out why rustc won't build is another issue.

Also, another thing I'm noticing is that regardless of what I put in meta.platforms, it always says the system is unsupported when building with pkgsCross.wasm32-unknown-none, and I always have to add NIXPKGS_ALLOW_UNSUPPORTED_SYSTEM=1 and --impure everytime I build 🫠 I might look into addressing this too.

13:04:21
@mindtree:matrix.orgmindtree *

Update: while the above^ works on aarch64-darwin as the build machine, I'm now running into issues when using x86_64-linux as the build machine.

It looks like even when just building a hello-world rust program with rustPlatform.buildrustPackage via pkgs.pkgsCross.wasm32-unknown-none.callPackage, it starts compiling LLVM and then rustc from scratch.

This was kind of expected after my experience on my mac, where the same happened, however on the mac they at least complete successfully after an hour or two. On my linux build machine, rustc fails to build during the bootstrap phase with a libunwind .so not found error.

Shouldn't llvm and rustc be cached for the pkgsCross.wasm32-unknown-none? Perhaps they're not, because there are no packages that actually use pkgsCross.wasm32-unknown-none, so as a result hydra never builds and caches them?

If so, what would be the best way to get hydra testing and building these? Would I need to add some simple hello-world-rust-wasm32-unknown-none package to pkgs/by-name/he/ or something along these lines?

I guess working out why rustc won't build is another issue, but at least having some basic pkg in nixpkgs would help to ensure it stays working.

Also, another thing I'm noticing is that regardless of what I put in meta.platforms, it always says the system is unsupported when building with pkgsCross.wasm32-unknown-none, and I always have to add NIXPKGS_ALLOW_UNSUPPORTED_SYSTEM=1 and --impure everytime I build 🫠 I might look into addressing this too.

13:04:36
@mindtree:matrix.orgmindtree *

Update: while the above^ works on aarch64-darwin as the build machine, I'm now running into issues when using x86_64-linux as the build machine.

It looks like even when just building a hello-world rust program with rustPlatform.buildRustPackage via pkgs.pkgsCross.wasm32-unknown-none.callPackage, it starts compiling LLVM and then rustc from scratch.

This was kind of expected after my experience on my mac, where the same happened, however on the mac they at least complete successfully after an hour or two. On my linux build machine, rustc fails to build during the bootstrap phase with a libunwind .so not found error.

Shouldn't llvm and rustc be cached for the pkgsCross.wasm32-unknown-none? Perhaps they're not, because there are no packages that actually use pkgsCross.wasm32-unknown-none, so as a result hydra never builds and caches them?

If so, what would be the best way to get hydra testing and building these? Would I need to add some simple hello-world-rust-wasm32-unknown-none package to pkgs/by-name/he/ or something along these lines?

I guess working out why rustc won't build is another issue, but at least having some basic pkg in nixpkgs would help to ensure it stays working.

Also, another thing I'm noticing is that regardless of what I put in meta.platforms, it always says the system is unsupported when building with pkgsCross.wasm32-unknown-none, and I always have to add NIXPKGS_ALLOW_UNSUPPORTED_SYSTEM=1 and --impure everytime I build 🫠 I might look into addressing this too.

13:22:10
@qyliss:fairydust.spaceAlyssa Rosswell, they can't be cached if they don't build17:55:19
@qyliss:fairydust.spaceAlyssa Rossthe thing with Hydra "testing" things is that it's only helpful if somebody is actively monitoring Hydra to see if something stops building, because Hydra doesn't do anything to notify of failed builds17:56:30
@rosscomputerguy:matrix.orgTristan RossIt would be useful if it could but then emails would be flooded and likely ignored.18:09:11
9 Feb 2025
@tired:fairydust.space@tired:fairydust.space left the room.22:50:47
10 Feb 2025
@rhelmot:matrix.orgrhelmotdoes anyone wanna explain how the splicing internals work to me03:58:07
@artturin:matrix.orgArtturinEasy, it's just adding attrs on top of the package set03:58:47
@artturin:matrix.orgArtturinFrom other offset package sets03:59:12
@rhelmot:matrix.orgrhelmotI mean like the stuff where derivations added to specific lists in mkDerivation automatically get turned into derivations from one of the spliced pkgsets03:59:34
@artturin:matrix.orgArtturin* Easy, it's just adding attrs to package attrs on top of the package set03:59:37
@rhelmot:matrix.orgrhelmotif there's a better word for that process I'd love to hear it lol03:59:53
@artturin:matrix.orgArtturinThat's the simplest part of the whole splicing thing 04:00:39
@artturin:matrix.orgArtturinhttps://github.com/NixOS/nixpkgs/blob/f202c36babad2412fc20a061d56c1f378efa806d/pkgs/stdenv/generic/make-derivation.nix#L34604:00:41

Show newer messages


Back to Room ListRoom Version: 6