!ayCRiZriCVtuCUpeLp:nixos.org

Nix Cross Compiling

579 Members
126 Servers

Load older messages


SenderMessageTime
7 Feb 2025
@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
@rhelmot:matrix.orgrhelmotas far as I can tell it pulls stuff out of drv.__spliced.pkgsSomethingSomething which is provided by splice.nix but __spliced isn't present in nix repl04:00:41
@artturin:matrix.orgArtturincallPackage gets packaged from __splicedPackages04:01:05
@artturin:matrix.orgArtturin* callPackage gets packages from __splicedPackages04:01:21
@artturin:matrix.orgArtturin* callPackage gets attrs from __splicedPackages04:01:28
@artturin:matrix.orgArtturinpkgsCross.X.__splicedPackages to access them04:01:55
@rhelmot:matrix.orgrhelmothm04:02:24
@rhelmot:matrix.orgrhelmotwhat's special about pkgsCross that causes __splicedPackages to contain the __spliced attribute but not the toplevel04:03:03

Show newer messages


Back to Room ListRoom Version: 6