Hacker News Reader

Comment by no_time | Hacker News Reader

How about forgetting glibc alltogether and statically linking musl?

Can you explain the glibc hate? Been using it for 20+ years and really confused why people dislike it.

Because you won’t be able to run your program on a HPC cluster that runs CentOS 7 with an ancient glibc, if you wrote it in C++17 on your Fedora machine. Or basically anywhere else.

It will be much easier with musl.

This hits close to home. We have a handful of versions of GCC and library paths for this reason.

ROCKS never upgraded to CentOS 8, new hardware support is becoming an issue, so moving to a new cluster manager and a newer Rocky/Alma/? has been a long time coming.

Probably because of just that, it's old and not cool anymore.

I can't speak for other use cases, but trying a musl based distro on restricted hardware convinced me how good it is. Memory/storage consumption is reduced by a a lot compared to glibc, and it's damn fast. Now I try to run Alpine wherever I need compactness and simplicity.

I'm not a real "glibc hater" apart from my (limited) experience of it being the no. 1 roadblock in getting linux binaries to just work.

Also, a lot of forum posts like to imply there is some kind of technical issue with statically linking it. As opposed to musl, which even provides a handy wrapper that just works.

glibc is far from the no1 roadblock, if a program doesn't use undocumented/private features it will work for decades. This example [0] shows a program i wrote compiled on Red Hat linux from 1997 (ignore the broken colors, the program assumed 24bit/8bcc X server) dynamically linking against libX11 and glibc running on 2017 Debian (i took the shot in 2017), showing two decades of backwards compatibility with both the GNU C library and X11.

If a program that links dynamically to the GNU C library doesn't work the reason is either some other library or the program doing something screwy with glibc that it shouldn't do - but in that case that program wouldn't compile with musl either since it'd be touching glibc internals.

[0] https://i.imgur.com/YxGNB7h.png

The top 1 reason is that the developer build the binary with newer glibc than users'. And of course your users use older system than yours.

Of course, if everyone builds their binary with glibc from 1997 it would just work. /s

No "/s", it'd actually work :-P.

However yes, this is an issue though AFAIK that is more of an ld issue than a glibc issue - you'd have the same problems with other libraries too.

From the post i replied, i understood that problem as a users' problem for running existing binaries (most binaries are using some older version to avoid that issue and in general people who use Linux tend to have the latest version of stuff due to how non-intrusive updates are), which shouldn't be a problem. It can be a bit of a PITA from the developer side though.

For other libraries I simply YOLO-ed it and statically linked everything. Can't do the same for glibc.

Yes, I ship security vulnerability to my users (and am responsible to fix it after every OpenSSL/curl/libpng/... advisory). Still MUCH better than shipping non-working broken shit to users.

Worse: where do you get a 1997 era glibc for your current system? Nowhere, that's where. You need a container with a 1997 era distro, minumum.

Yes but that's ok, the article even mentions it with Debian 7 as an example. 1997 is indeed a bit extreme but going through the hassle once for your build setup should be acceptable pain.

I maintained a sysroot with glibc 2.17 (it was 2.12 before when there are still CentOS 6 presence), built with latest GCC, for $DAYJOB. You can then use whatever modern toolchain you like (be it Clang+LLD or latest GCC+binutils), just point sysroot to it. Runs everywhere, don't need a container with old distro.

Wasn't too bad, but definitely takes ~0.2 SDE to maintain.

musl doesn't support NSS properly as far as I can see, and glibc won't support it when statically linked.

So it's fine if you're running an app on a system or a container where everything is in /etc/passwd, /etc/services, /etc/hosts etc. Meanwhile back in the real world people who need their applications to work for NSS sources other than any of those will probably stick to dynamically linking glibc.

Reply on news.ycombinator.com