I made .nix file that allows you to cross-compile packages in nixpkgs using zig.
This is useful as zig doesn’t need heavy bootsrapping, and can compile to various targets out of the box.
I’m using this personally right now, there’s few issues that are mostly upstream bugs however.
I might turn this into more fleshed out project that provides also overlay and support scripts for fetching nix binary releases.
(I was aware of zicross, but it does not integrate into stdenv as I do here)
Can you spell out some more your gauging of the benefits of “doesn’t need heavy boostrapping”? This is an interesting lead, but I just have too little context at this moment to really kick off my fantasy.
There’s github action that updates the zig-binaries.json automatically. I also want to automate automatic tests that will catch the most broken targets and track them. I think this would help upstream as well.
This is what current master produces for “iniparser”, I chose this package for initial testing as it does not use autotools nor autotools deps so it doesn’t have to spend ages checking for the most useless things before actually compiling some code.
In addition I’m using this to cross-compile rust code to aarch64 AWS lambdas as static musl binaries.
@blaggacao
The idea is that zig provides C/C++ compiler for major platforms that can cross-compile to different targets out of the box. This means you don’t have to bootstrap every combination of cross-compiler toolchains (binutils, libc, libstdc++, etc…) from scratch each time, which can take quite a bit of time. It might save time for people, or perhaps make nix cross-compilation better in future regards of shared binary cache.
If you read the blog post linked above, you’ll know that it’s built on top of clang.
It looks useful for cross-compilation as it does many things better than other compiler front-ends in this regard but perhaps not too interesting for bootstrapping Nixpkgs as you’d still need clang to build this and at that point we might as well bootstrap on clang.
Major milestone, deno / rusty_v8 / v8 builds on linux. Though arguably with help of binfmt and qemu-static-user for those few pesky binaries the build system wants to execute. Needlessly said, gn is not my favorite build system
Anyhow, there’s some promise here. However zig is still fresh so there’s bunch of stuff that needs to be fixed upstream.
/nix/store/zqik2z7dxn57z66kqf0qymjbfb8smmlz-hello-world-0.1.0-aarch64-unknown-linux-musl/bin/lambda-hello-world: ELF 64-bit LSB executable, ARM aarch64, version 1 (SYSV), statically linked, not stripped
[130] void@voidlinux> ./result/bin/lambda-hello-world
v8 version: 10.8.168.4
thread 'main' panicked at 'Missing AWS_LAMBDA_FUNCTION_NAME env var: NotPresent', /sources/lambda_runtime-0.7.0/src/lib.rs:62:65
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
qemu: uncaught target signal 6 (Aborted) - core dumped
There is now basic framework for testing builds:
While this will be important for this project for various reasons such as automatic metadata generation, automatic github workflow generation, and regression testing, it may provide good resource for zig developers as well, so I might talk to them later.
