lib.systems: introduce toolchain, cc, and bintools attributes

[RossComputerGuy]

Things done

Replaces useLLVM, useArocc, and useZig with toolchain, cc, linker, and bintools attributes. This might not produce any rebuilds but we'll see. This has the advantage of preventing using${compiler} flags from colliding and not working correctly if we were to stack multiple pkgs* together.

• 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/)
• 25.05 Release Notes (or backporting 24.11 and 25.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.

[tomberek]

The main idea and motivation is in: pkgs/stdenv/cross/default.nix

[philiptaron]

I like the direction this is going in -- if there's an enum, make it be an enum, not a set of booleans.

I'd appreciate a "next steps" portion of this PR, where you give some guidance on how and what's going to happen next, especially if there are breaking changes.

[RossComputerGuy]

I'd appreciate a "next steps" portion of this PR

Next step is to add exports for LD or change exports for LD to the linker explicitly set. The idea is the bintools and linker can be less connected. From there, it'll probably be more explicit defining of the CC and other tools. Maybe a setup hook inside CC wrapper or other stuff could do it. Then I'll redo my CPU model PR and make some of that optimization stuff more flexible between different compilers.

where you give some guidance on how and what's going to happen next, especially if there are breaking changes.

Probably any other things we could look into doing that makes it easier to add an LLVM bootstrap to Linux.

[pwaller]

Hmm. I like the design. But I wonder about backwards compatibility. Will users suddenly experience this not working as expected in their existing expressions?

(orthogonal) Ideas:

1. Support the old attributes, rewriting them as the new.
2. Put assertions in that fire if the old attributes are in use.
3. (alternatively, emit trace deprecation warnings)
4. Catch the case where users supply something invalid. (Currently they can put anything in there, which can be confusing if there is a typo and things don't work as intended).

I don't know what level of support users should expect of these (existing) attributes, but I can say that I would probably find things quite confusing when this lands, had I not seen this PR.

[RossComputerGuy]

Will users suddenly experience this not working as expected in their existing expressions?

Yeah, it'll just not work lol

1. Support the old attributes, rewriting them as the new.

Tried as a warning or throw but it was causing stdenv to fail.

2. Put assertions in that fire if the old attributes are in use.

This could work, I can easily add in asserts to the platform stuff to make that work.

3. (alternatively, emit trace deprecation warnings)

Mentioned earlier, tried this. We'd see like 8 warning every time stdenv is used.

4. Catch the case where users supply something invalid. (Currently they can put anything in there, which can be confusing if there is a typo and things don't work as intended).

This is likely the simplest and best solution. Add a few asserts which check to ensure nobody is passing the deprecated attributes.

[pwaller]

It is possible to use clang with the GCC runtimes. Is a straightforward expression available here which would be of the form f stdenv where it would return true if compiler-rt was in use and false if gcc was in use? This question is independent of whether the llvm toolchain is in use, because you can use a clang compiler with the gcc standard libraries, and there are cases where it is useful to be able to detect this situation.

Today for instance clangStdenv.hostPlatform.useLLVM returns false; would the equivalent in the new world be clangStdenv.hostPlatform.toolchain == "gcc", and is that weird?

[RossComputerGuy]

It is possible to use clang with the GCC runtimes.

Afaict, that's already possible and the default behavior on Linux.

[pwaller]

Afaict, that's already possible and the default behavior on Linux.

I realise, but just trying to think through the meaning of these new values (and also the old ones such as useLLVM); and whether they are clear and expressive enough.

[RossComputerGuy]

These new values are more fine grain, useLLVM already conveyed to use the LLVM toolchain. The compiler attribute only switches out the compiler being used. Linker only will change the linker and bintools changes the binary tools. However, toolchain is a more "global" control that changes all the options. This allows for more precise control over the platform's build environment.

[Ericson2314]

(just glanced, this is a conceptual review)

I knee this day would come :)

[reckenrode]

Darwin’s toolchain is mostly LLVM. It uses clang. It uses most LLVM bintools except for a handful of things:

• ld64. Other linkers aren’t yet drop-in replacements. It could be changed to ld-prime if the source is ever released (which I doubt it will be) or another linker if it improves enough. The linker value is currently cctools, but that’s not really right. cctools has a linker, but it’s not built. I believe it’s ld64’s predecessor.
• lipo and install_name_tool. LLVM has replacements, but they crash (llvm-lipo crashes in Meson’s test suite) or are missing features (llvm-install-name-tool does not support LC_REEXPORT_DYLIB).
• llvm-ranlib is not a drop-in replacement for ranlib from cctools, though this could probably be patched around.
• gperf is included just because, though it’s probably not needed in darwin.binutils. codesign_allocate can probably be dropped. Those who need it can get it from cctools directly.

How would Darwin be represented in this taxonomy? toolchain = apple, cc = clang, bintools = llvm, linker = ld64?

[RossComputerGuy]

How would Darwin be represented in this taxonomy? ``

Darwin is an odd one

toolchain = apple, cc = clang, bintools = llvm, linker = ld64

That is close, the linker defaults to cctools. I don't think we'd support changing these options much outside of Linux. It's just simpler enough to support as is outside of Linux.

[reckenrode]

That is close, the linker defaults to cctools. I don't think we'd support changing these options much outside of Linux. It's just simpler enough to support as is outside of Linux.

It’s currently cctools, but I’m suggesting it ought to be ld64 since that’s the actual linker being used. Given that there are other linkers available for Darwin (such as lld and emerald), it would be nice if changing the linker also worked for Darwin. (I assume changing cc to gcc is also expected to work? Is that potentially an alternative to using gccStdenv?)

[reckenrode]

I’ll add that addressing Darwin support beyond the default doesn’t have to be part of this PR, but I would like to see what such support would like so it can be addressed separately.

[RossComputerGuy]

It’s currently cctools, but I’m suggesting it ought to be ld64 since that’s the actual linker being used.

Oh gotcha

Given that there are other linkers available for Darwin (such as lld and emerald), it would be nice if changing the linker also worked for Darwin

Yeah, I can make that happen once I start making the linker attribute work separately from bintools in my follow up PR.

I assume changing cc to gcc is also expected to work?

It should, I'm not sure whether it actually does work as intended.

Is that potentially an alternative to using gccStdenv?

It can be, it applies through everything using stdenv rather than an explicit stdenv.