Yay for Clang

Posted Jan 25, 2026 21:36 UTC (Sun) by josh (subscriber, #17465)
In reply to: Yay for Clang by willy
Parent article: GNU C Library 2.43 released

Also, relatedly, people always say things like "make systemd support musl" rather than "make musl support systemd"; there's always a direction to the entitlement. systemd didn't (past tense, they're adding basic musl support now) compile on musl because musl was missing functionality systemd expected. And systemd's current partial support for musl still reflects that:

> Incomplete support for musl libc is now available by setting the "libc" meson option to "musl". Note that systemd compiled with musl has various limitations: since NSS or equivalent functionality is not available, nss-systemd, nss-resolve, DynamicUser=, systemd-homed, systemd-userdbd, the foreign UID ID, unprivileged systemd-nspawn, systemd-nsresourced, and so on will not work. Also, the usual memory pressure behaviour of long-running systemd services has no effect on musl. We also implemented a bunch of shims and workarounds to support compiling and running with musl. Caveat emptor.

I appreciate musl (other than the slide towards permissive license), and I use musl for some use cases, but it *is* missing functionality. (NSS is awful, but it's an awfulness people rely on, so there needs to be a sufficiently compatible replacement. And that's not the only thing it's missing.)

Similarly, people say "GNOME should support non-systemd" rather than "non-systemd should add the functionality GNOME is relying on". And if you try to bring that up, it leads to one of the "well, systemd does too much" tirades. Turns out people *do* want that functionality. People wrote the software, people want to use the software, and at some point people want to stop having to support the less functional alternative.

to post comments

Yay for Clang

Posted Jan 25, 2026 22:32 UTC (Sun) by Cyberax (✭ supporter ✭, #52523) [Link] (6 responses)

On the other hand, musl taking a principled stance against broken PAM and NSS can result in a better overall architecture. As people are forced to deal with not having these systems.

Otherwise, there's just no pressure to change anything.

Yay for Clang

Posted Jan 25, 2026 22:46 UTC (Sun) by josh (subscriber, #17465) [Link] (5 responses)

I'm all for them taking a stand against PAM and NSS. But then, they need a strategy for a replacement. Not just "oh, don't use those", but a solution. For instance, a daemon that loads any NSS module and speaks some reasonable protocol that musl will check for by default.

Yay for Clang

Posted Jan 25, 2026 23:00 UTC (Sun) by Cyberax (✭ supporter ✭, #52523) [Link] (4 responses)

The solution is NSCD, it's supported natively by musl for NSS.

Yay for Clang

Posted Jan 26, 2026 3:59 UTC (Mon) by josh (subscriber, #17465) [Link] (3 responses)

Interesting. That appears to be new as of less than a year ago, but it does look promising. That's helpful. Perhaps distros should be adding that to Recommends or equivalent now.

Yay for Clang

Posted Jan 26, 2026 6:37 UTC (Mon) by joib (subscriber, #8541) [Link] (1 responses)

NSCD the protocol might be decent enough(?), but nscd the daemon is a horrible architecture, and said architecture is a big reason why it has largely been replaced with sssd.

Yay for Clang

Posted Jan 26, 2026 8:01 UTC (Mon) by Cyberax (✭ supporter ✭, #52523) [Link]

The NSCD daemon itself is a mess, but the NSCD protocol is dead simple. There is even a bridge allowing the use of NSS modules via NSCD: https://github.com/pikhq/musl-nscd/tree/master

It basically was ignored by everyone.

Yay for Clang

Posted Jan 26, 2026 7:57 UTC (Mon) by Cyberax (✭ supporter ✭, #52523) [Link]

NSCD has been supported in musl for more than a decade: https://github.com/kraj/musl/commits/ff441c9ddfefbb94e588...

Yay for Clang

Posted Jan 27, 2026 0:48 UTC (Tue) by turistu (guest, #164830) [Link] (2 responses)

> Also, the usual memory pressure behaviour of long-running systemd services has no effect on musl.

Can someone explain what they're trying to say in that hedged, convoluted statement?

Is it that musl's free(3) never ends up calling brk(2) or munmap(2) to actually release the freed up memory?

Yay for Clang

Posted Jan 27, 2026 8:05 UTC (Tue) by mchapman (subscriber, #66589) [Link] (1 responses)

Under memory pressure, systemd's daemons call malloc_trim to ask the C library to release unused heap space. This function isn't implemented by Musl.

It might be the case that Musl doesn't need it. But I think that would mean it would be mapping and unmapping single pages at a time, which doesn't seem likely.

Yay for Clang

Posted Jan 27, 2026 11:44 UTC (Tue) by wahern (subscriber, #37304) [Link]

musl does return memory to the kernel. See free at https://git.musl-libc.org/cgit/musl/tree/src/malloc/mallo... I haven't read closely enough to really understand the heuristics, or the general architecture for that matter, but off-the-cuff I'd guess it's pretty aggressive, but not stupid aggressive. It shouldn't be too difficult to explore. The code is incredibly short compared to ptmalloc, etc; not just free.c, but all of mallocng/.

Yay for Clang

Posted Jan 27, 2026 9:15 UTC (Tue) by jmalcolm (subscriber, #8876) [Link]

> people say "GNOME should support non-systemd" rather than "non-systemd should add the functionality GNOME is relying on"

I use Chimera Linux which does not use systemd. When GNOME announced their changes, the lead Chimera Linux dev very quickly announced that they would be doing the work to make GNOME. And this is the way it should be.

https://gts.q66.moe/@q66/statuses/01JXFJWFGBSB1KK9E7Y8JBFQN4

As before though, my complaint will be about how open GNOME is to accepting patches from other projects. GNOME does not have to do the work. But I hope they do not block it either.

And as with the NSS discussion in other comments, there is a difference between completely lacking a required capability and simply not using the exact API we want you to.