lib.systems: add various has* flags useful for embedded systems

[kuruczgy]

Things done

• Built on platform(s)
  • x86_64-linux
  • aarch64-linux
  • x86_64-darwin
  • aarch64-darwin
• For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)
  • sandbox = relaxed
  • sandbox = true
• Tested, as applicable:
  • NixOS test(s) (look inside nixos/tests)
  • and/or package tests
  • or, for functions and "core" functionality, tests in lib/tests or pkgs/test
  • made sure NixOS tests are linked to the relevant packages
• Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
• Tested basic functionality of all binary files (usually in ./result/bin/)
• 24.11 Release Notes (or backporting 23.11 and 24.05 Release notes)
  • (Package updates) Added a release notes entry if the change is major or breaking
  • (Module updates) Added a release notes entry if the change is significant
  • (Module addition) Added a release notes entry if adding a new NixOS module
• Fits CONTRIBUTING.md.

---

Add a 👍 reaction to pull requests you find important.

[FliegendeWurst]

Should target staging

[kuruczgy]

Thank you both for the feedback.

Before continuing with this, I would like some feedback from someone on the high level concept first. (E.g. the concept is fine, and we don't need to rethink and use some other approach.)

If it's confirmed that this is desirable change, I can update the PR to a non-draft quality one. (Split the two linunwind cases, fix the typos, fix the formatting, rebase onto latest master.)

[FliegendeWurst]

I think the concept is fine. To convince more people I would suggest showing a use for each new condition.

[kuruczgy]

Updated, the major new change is that I now have two separate hasSystemLibunwind and hasStackUnwinding flags. My assumption is that Darwin and FreeBSD want to use a libunwind that comes from "somewhere else" (I assume stdenv handles this for those platforms), though I still had to add some exceptions to match the previous behavior. If someone has knowledge of these platforms please weigh on whether these exceptions are actually needed or were just accidental inconsistencies of the previous logic.

If someone is interested in somewhat of a "real world" use-case for this code, here is my example which originally motivated these changes: https://github.com/kuruczgy/lean-esp32/blob/c912a815d079cd5a3d029771c247e692f5516b71/flake.nix

Notably, targeting embedded platforms using nixpkgs is still very rough, so I expect several more changes to be needed, for example support for picolibc or some saner defaults for the hardening flags (currently a lot of them can blow up code size).

[kuruczgy]

I believe it should be good now, I changed all references to targetPlatform in the libcxx derivation to hostPlatform.

[alyssais]

This looks great! I like how it's exposing all these Darwin/FreeBSD inconsistencies. I've reviewed the lib changes, and ack the package changes but haven't thoroughly reviewed them.

[reckenrode]

I need to look over the Darwin changes more closely, but some of the changes appear to be adding the libunwind package on Darwin, which doesn’t seem right. Darwin ships and links libunwind implicitly via libSystem.

[RossComputerGuy]

I don't think this works since we have multiple unwinder implementations.

• LLVM libunwind
• Darwin libunwind
• non-GNU libunwind
• GCC's unwinder

Instead, I think treating it like an enum like #365057 does works best imo.