Good, this was always incredibly confusing, and a hassle because it even needs Linux-specific code in otherwise completely platform-agnostic (cmake) build system files.

The other even more confusing thing is that -pthread/-lpthread may be needed even when your own code doesn't use pthreads at all (while at it, please also get rid of -pthread), but some dynamically linked dependency does (like linking with X11+GLX+GL) - which then doesn't just cause a linker error but a runtime crash with an entirely unrelated error message (but only on some Linux setups) - I hope the change will fix these problems too.

And hopefully the 'm' library is next (seems they intend to but it didn't make it into this release).

Btw, CMake has the [FindThreads][1] module to automatically link with `-lpthread`/`-pthread` in a platform-agnostic way.

Even after this change in glibc, you may still need to use FindThreads to handle [HP-UX][2] (some of which still run [Itanium][3]!!!).

[1]: https://cmake.org/cmake/help/latest/module/FindThreads.html

[2]: https://en.wikipedia.org/wiki/HP-UX

[3]: https://en.wikipedia.org/wiki/Itanium

Can you say more about that problem with transitive dependencies, e.g. x11?

Does it only happen when your code links in the static version of a library that requires pthreads?

All I can do is give you a couple of Github ticket links where users of my libraries stumbled over the issue (and with different symptoms):

- https://github.com/floooh/sokol/issues/376

- https://github.com/floooh/sokol/issues/404

- https://github.com/floooh/cimgui-sokol-starterkit/issues/6

We then added a dummy call to a no-op pthread function, so that users at least get a pthread-related linker error and can figure out that they need the -pthread/-lpthread options instead of running into random runtime problems:

- https://github.com/floooh/sokol/pull/456

Also, on my Ubuntu laptop this problem didn't happen, that's why I didn't catch it during development, it seems to be specific to some distros or personal config changes.

The affected code bases don't use threading and didn't link pthread before (neither statically nor dynamically).

Why does glibc has to care about what systemd does ? I thought they are separate.

The article mentions `nss_systemd`.

NSS allows Linux systems to provide custom ways to look up users and groups.

https://en.m.wikipedia.org/wiki/Name_Service_Switch

https://www.man7.org/linux/man-pages/man5/nsswitch.conf.5.ht... says this is implemented by having a shared object library for each "service".

https://www.freedesktop.org/software/systemd/man/nss-systemd... says `nss_systemd` is mainly for systemd's DynamicUser feature.

https://www.freedesktop.org/software/systemd/man/systemd.exe... documents that setting:

> DynamicUser=

> Takes a boolean parameter. If set, a UNIX user and group pair is allocated dynamically when the unit is started, and released as soon as it is stopped. The user and group will not be added to /etc/passwd or /etc/group, but are managed transiently during runtime

https://www.redhat.com/sysadmin/systemd-secure-services explains that this is for sandboxing.

The glibc docs explain nsswitch well.

https://www.gnu.org/software/libc/manual/html_node/Name-Serv...

https://www.gnu.org/software/libc/manual/html_node/Adding-an... in particular, which explains how to write a custom NSS service as a shared library.

I expect the concern the article raises applies to all custom NSS services, such as:

- sssd: https://ubuntu.com/server/docs/service-sssd-ad

- nsscache: https://github.com/google/nsscache

My reading is that systemd was just used as an example of the benefit of this change. It could be any software which loads separate parts of glibc and so could run into problems during libc upgrade. Now with this idea of one shared object from musl, the entire system becomes more resilient. systemd is a benefactor but not the only one nor the reason for the change.