Change:
githubId = 34161949; keys = [ { fingerprint = "155C F413 0129 C058 9A5F  5524 3658 73F2 F0C6 153B"; } ]; }; <ins> sanana = { email = "asya@waifu.club"; github = "AsyaTheAbove"; githubId = 40492846; keys = [ { fingerprint = "B766 7717 1644 5ABC DE82  94AA 4679 BF7D CC04 4783"; } ]; name = "sanana the skenana"; }; </ins> sander = { email = "s.vanderburg@tudelft.nl"; github = "svanderburg";

Discussion:
Steps to reproduce the behavior: (behaviour is the same when trying to ) finding a riscv64 cross compiler toolchain. It asks for a RISC-V compiler because the package is configured with the flag, so it fails to compile if any architecture is missing. Can be worked around by just enabling it for the platform that you are targeting, so long as that isn't RISC-V... P.S: I only tried with the flag, and it seems to compile alright with that, but not with RISC-V. Thank you. Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
I can't reproduce the failure by running on my x86-64 Linux virtual machine and I currently don't have an aarch64/risc-v Linux virtual machine set up to test it on. Perhaps it is related to you trying to build it on macOS? I can't test that very easily as I don't use Nix on macOS, but I will try building Limine manually. Could you also post the full output of as suggested by the log? edit: I have no issues building Limine from a release tarball manually on my M1 MBA running macOS 14.0, llvm 17.0.6, nasm 2.16.02, GNU mtools 4.0.43 and GNU make 4.4.1
here it is
yeah, so if turns on ALL architectures according to the upstream then I don't think this is something desirable in nix.
I did a bit more research into building Limine's tools, the options enable UEFI or BIOS tooling, but are NOT responsible for architectures specifically. However, they do require it if trying to enable, e.g, , then you need the toolchain. When trying to compile , that automatically pulls in . Weirdly enough, I get the same i686 error that got (that I wasn't getting before?) when building it using the env.
I made a modded version of the package for only x8664 UEFI and x86 BIOS: Trying to build with this on macOS + Rosetta 2 (so x8664 Nix packages are included as well as aarch64), and now I'm getting errors from lld about unknown arguments.

When I the derivation to nixpkgs, I decided to use --enable-all with the intention to create a Bootable image on a x8664 platform that boots on all platforms. I think this is a valid use case, especially if you are creating an EFI application with Rust that you easily can compile for x86, aarch64, and riscv. You can embed this into a Limine iso and add legacy boot capabilities additionally into that image. Hence, I'd like to see the host tools being build for the host architecture but the bootloader files for all architectures. Unfortunately, I don't have an aarch64 or riscv system to that the build.. We might could add a condition to the derivation: if x8664 we build for all platforms, if we build on another architecture, we only build what the toolchain provides.
I'd personally disagree and argue that we should try to keep nix packages as similar as possible across all platforms to keep with consumer expectation of replicability, so keeping is probably a good call. I think we might need to change the for systems to fix this. , as it points out probably the exact problem we're having. I think this is why I'm getting all the incorrect argument errors -- by default, the wrong linker is being used because Apple just loves replacing the standard solution with their own home-grown garbage.
FYI: In someone removed darwin as platform.
Here to say that this is still a problem.
For context, this is a problem for all systems now, not just Darwin
I'll look into it and hopefully find a pragamatic solution soon
I think the best solution will be to build limine for current architecture only, other architectures should be built with if needed
I'll look into it. The idea to build it for all architectures is to not limit downstream users (OS programmers) when they crate bootable items for whatever architecture using Limine for their custom operating system project
Yeah, end users then can do something like while being eg. on a machine and nixpkgs will make sure that the will have a working crosscompiler for .

You can set build flags depending on architecture, this will be a good example buildPlatform/hostPlatform/targetPlatform might be confusing, there's an explanation here
Perhaps my mental model is wrong, but as long as a package can "fairly simple" cross-compile itself, it should do it, IMHO. Right? Limine can cross-compile easily with a clang/llvm toolchain but not a gcc toolchain. Btw: This is about cross-compiling the bootlaoder artifacts and NOT the limine host tool! This is a big difference! gcc is used to build the host tool for the host architecture and clang is used to cross-compile bootloader artifacts to create bootable images using the hosttool. This used to work nicely for quite a few months in nixpkgs. Further, upstream this also works (not in Nix environment): So my preferred solution is to make the clang/llvm build work again but keep if it is possible. I'll keep you posted. I don't want to spend too much time into it, but it is blocking my at the moment as well.
I noticed that the build fails because fails the step . Can it bee that changed recently (past 6 months) in nixpkgs and, unlike on Ubuntu, doesn't come with proper cross-compilation support anymore?
I'm not very happy but this is a pragmatic solution:
Made a more nixpkgs-like solution, I don't really like how the GNU/LLVM toolchains are currently mixed :/ tested and it builds but idk about darwin.
lmfao, using for both host tool and bootloader fails because of - there are GNU binutils in instead of LLVM tools. Limine needs Clang+LLVM toolchain or GCC+GNU toolchain, it can't be mixed finds clang, fails on because gives us GNU toolchain and starts looking for gcc which ofc doesn't exist.

I'll force-push my PR with allVariants toggle EDIT: actually it works now when using pkgsCross, but not when doing a regular build, wtf why tf is it suddenly looking for gcc if apparently it found everything from llvm for riscv64
It's possible to enforce LLVM only with which does this instead which is weird because everything was found according to logs above the error... edit: ok, that's because of
nixpkgs package broke when upstream RISC-V support here Because LLVM doesn't support zerocallusedregs hardening on RISC-V, it was silently failing here:
So to summarize: If we remove the hardening flag zerocallusedregs, the existing derivation works. To verify, run; I'm also happy with a configurable derivation, such as etc. As long as it can easily be configured using . Is this your plan for ? Thanks everyone for looking into this and working towards a solution!
I think it would be totally fine to just leave it as at is and disable zerocallusedregs for this package, if that's a solution you folks prefer.