I don't see anything to suggest that Arch uses eglibc. The glibc package in the repos is clearly the original glibc (look at the name, package URL, and build config) and there is no other package named "eglibc". Also, a very recent forum post[1] implies eglibc is not the standard.
Wikipedia says[2] that Arch uses eglibc, but their source is the eglibc website home page and I find no such claim on the entire site. I can't find anything about eglibc on the Arch mailing list, either.
oh yes, no code written in 2021 should use that mess. but a glibc being some level of posix compatibility.. hard to blame them for at least trying to make it work.
Ancient glibc versions run ok on current kernels, you're just missing out on some newer features. Otherwise statically linked binaries would cease to work.
Wow, Debian (and by extension Ubuntu) has been using eglibc for five years and I haven't noticed?
I even compiled new versions of gcc + glibc (and installed them into $HOME, to run new binaries on older installations). You think I should have noticed that there was no glibc on the host system to begin with. But actually, the only thing I noticed is that the glibc (and gcc) build system is a bit crazy, and that it definitely will benefit from a new project lead.
I remember some funny problems with Glibc, like, 20 years ago, but it's been invisible to me (as a user) since then. You get a new Glibc, old binaries still work, it's fine.
This looks like more of a case of glibc not working well with one particular combination of options. I don't think libc really holds anyone back considering it does still expose a syscall wrapper.
A lot of this page dates back to a few years back when glibc had severe bugs in its maintainer, and the eglibc branch/fork was the better choice. Regardless, given the commonalities of the codebases, it's doubtful that the numbers between glibc and eglibc are going to be much different.
Protip: eglibc is a fork of glibc, considers glibc an upstream, and communicates patches with glibc, requiring copyright reassignment for contributed code. This makes them roughly as GNU as glibc itself, which is maintained by a Redhat employee.
Glibc is a nasty piece of software full of nonstandard GNUisms that basically implements a separate standard. I've fought for years against the fact they've got functions that are not found in any other libc and have different behaviours depending on macros, often conflicting with POSIX or BSD variants.
The fact the project was run for almost 20 years by a guy that managed it in a dictatorial style was a huge reason why so many alternative libc existed (that, and the licensing). Few people here remember about EGLIBC I guess.
Glibc is also such a mess that it still does not compile with Clang, after _decades_, due to all the crazy GCC extensions they rely on. An attempt is cyclically started and then promptly aborted when some new crazy nonsense is found. For instance, last time I checked they not only used the completely insane folly that GCC nested functions are, but they also relied on GCC attributes so nasty that LLVM never bothered implemented them (like renaming functions at code generation). Using these extensions are not really necessary, and I've a strong suspicious it was more of an attempt by the GNU authors to prevent distributions to ever consider not using GCC as their main compiler.
Also how name resolution is implemented in Glibc means you can't really statically link with it. If you've ever noticed, most "statically linked executables" are not in fact statically linked, but require ld.so just for libc. There are good reasons to disallow statically linking libc, but this is not one of them. Especially since the only stable API on Linux is the kernel interface, so the only way to not have to worry about future Glibc breakage is to either link with Musl or live with the risk.
reply