3 ms·

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

atemerev 4y ago
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.
- bluedino 4y ago
  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.
TheChaplain 4y ago
Probably because of just that, it's old and not cool anymore.
- deleted 4y ago
  [deleted]
squarefoot 4y ago
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.
no_time 4y ago
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.
- badsectoracula 4y ago
  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 https://i.imgur.com/YxGNB7h.png
  - rfoo 4y ago
    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
    - badsectoracula 4y ago
      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.
      - rfoo 4y ago
        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.

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.

bluedino 4y ago
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.

TheChaplain 4y ago

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

deleted 4y ago
[deleted]

squarefoot 4y ago

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.

no_time 4y ago

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.

badsectoracula 4y ago
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 https://i.imgur.com/YxGNB7h.png
- rfoo 4y ago
  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
  - badsectoracula 4y ago
    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.
    - rfoo 4y ago
      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.