llvmPackages.libc: init at 20.0.0-unstable-2024-12-08

[RossComputerGuy]

Things done

Adds LLVM libc, we've got the overlay building but full is still kinda borked. We're only going to support from >= LLVM 20 because it requires a lot of patching in previous versions. We're hoping the inclusion of LLVM libc at the point it is right now could help further its development and we can figure out how to package it better early on.

• 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.

[alyssais]

The non-full variant doesn't seem to be used?

[RossComputerGuy]

As of this time, the overlay build isn't a dependency for anything.

[alyssais]

What is "the overlay build"? I don't see it explained anywhere here.

[RossComputerGuy]

The overlay build is the non full build of LLVM libc.

[alyssais]

What's the point of it?

[RossComputerGuy]

I asked the LLVM libc team on their Discord server:

Statically link a few libc dependencies, it's mostly a concession to make it usable until we can provide a complete C library

[alyssais]

What does "kinda borked" mean?

[RossComputerGuy]

The full build has some problems still needing to be worked out. There's some odd C++ errors preventing compiling. Overlay builds work.

[alyssais]

So then why add two attributes, one that works and one that doesn't? Why not just one libc attribute that builds as much as we can?

Is this actually useful for anything yet? If not, maybe we should just wait until we can at least build it properly.

[RossComputerGuy]

I was recommended to have both as an option since it'll allow for flexibility if things are broken. I'm going to be working on fixing the full build soon, just haven't gotten time. I've got some PR's merged upstream and some other might've flown under my radar so it could be working.

[alyssais]

For flexibility, wouldn't a single attribute with an option we could flip be better? Otherwise, we'd have to change everything that referred to the attribute all at once if we wanted to go from full to overlay.

[RossComputerGuy]

My thinking was to probably have 3, two are the actual builds and one is an alias. I think other parts of LLVM does this already in nixpkgs.

[alyssais]

But if the full build is working, why would we ever need the alias? Why does it need an attribute too?

[RossComputerGuy]

We already have to set a boolean anyways for full builds. The dependencies are different too. Providing both makes it easier to test if both work and for people to experiment with.

[alyssais]

If full is building, why would I want to test with overlay?

[RossComputerGuy]

I was meaning people who write software using nix could try it out. I know some people who would want to try it out.

[alyssais]

Yes, but is there a reason they'd specifically want to test out the non-full version, even if full is available and building?

[alyssais]

OOC does it make sense to ever use LLVM libc with GCC?

[RossComputerGuy]

Hard to say based on whether GCC supports the naked attribute for specific targets. I was thinking the LLVM abi which means to use the libc that it'd make sense to use the entire toolchain. That's what the team upstream thinks as well.

[alyssais]

Certainly we'd want $arch-unknown-linux-llvm to use both an LLVM toolchain and libc, but I'm not sure about pkgsLLVMLibc — I think it's a bit surprising that it works differently from pkgsMusl and replaces the toolchain as well. Having it only change the libc would make it more composable (with #303849), and still allow getting to an LLVM toolchain+libc combination with pkgsLLVM.pkgsLLVMLibc.

[RossComputerGuy]

Yeah, I could drop the LLVM toolchain part once the composable PR lands. It won't work properly without it.

[alyssais]

Sounds good, except maybe then we should just wait for that PR to add this attr, so we don't make a breaking change to it later? It'll still be possible to use LLVM libc by calling Nixpkgs with the appropriate triple.

[RossComputerGuy]

I figured out pkgsLLVM.pkgsLLVMLibc actually doesn't require the composable PR so it should eval right.

[alyssais]

Eval failure

[RossComputerGuy]

Eval should be fixed now

[RossComputerGuy]

Will likely merge this tomorrow, libunwind and libcxx don't quite work but there's possible fixes. The LLVM libc monthly meeting is tomorrow so I'm hoping to figure out how we can get those building.

[Mic92]

This might have broken the r-ryantm-updates bot? nix-community/infra#1676

[emilazy]

cc @infinisil shouldn't this have been caught by CI?

[RossComputerGuy]

I was thinking the same thing now that you mention it, I'm not sure why CI didn't catch it.

[infinisil]

Might be a case of nix-community/infra#1180

Edit: Nope