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]

LLVM libc doesn't implement every libc function yet so overlay mode is a compromise which it overlays on top the existing libc.

Got it. In that case, we should probably support both in libcCrossChooser, so people can easily switch between them, right? The reason this looked wrong to me at the start was that there was no way to really use one of them.

[RossComputerGuy]

We'd need some sort of stub libc in the overlay one to pull in both since the overlay uses a different library name.

[alyssais]

Oh, it's not called libc? That's weird — how is it supposed to be used then?

[RossComputerGuy]

Oh, it's not called libc?

libllvmlibc.a

That's weird — how is it supposed to be used then?

-llvmlibc

[alyssais]

Oh, it's not called libc?

libllvmlibc.a

That's weird — how is it supposed to be used then?

-llvmlibc

With -nostdlib I guess?

[RossComputerGuy]

No, you need a libc to overlay on top of. So you'd have both.

[alyssais]

I think this attribute being for two different things depending on the platform is going to be confusing.

[RossComputerGuy]

Tbf, we already have attributes which confuse people. clangUseLLVM, compiler-rt, stdenv.

[alyssais]

And that's justification to make things more confusing??

[RossComputerGuy]

Well I think it's not that confusing, it'll cause some accidents until someone realizes which one they should use if they need it. The lib names are different between the two so someone could easily tell when things go wrong when an error happens. Also, documenting the attributes better would help a lot.

[alyssais]

So why not make it explicit whether full or overlay is being used? As we've established, they're used completely differently, so there isn't a situation where you'd want an attribute that was sometimes the overlay and sometimes full.

[RossComputerGuy]

My thinking was having a shim which adds in both inside the overlay mode. Then the function which selects the libc cross could detect when to use the overlay mode. That could allow for mixing LLVM libc and glibc or LLVM libc and musl.

[RossComputerGuy]

From what I know, a shim can be made by writing a linker script into libc.so.

[alyssais]

Then how about we hold off on this attribute until that's ready to go? It's not really useful as it is.

[RossComputerGuy]

I've added the shim.

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