8 ms·

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 po

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.
  - AnIdiotOnTheNet 4y ago
    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.
    - iforgotpassword 4y ago
      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.
    - rfoo 4y ago
      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.
nineteen999 4y ago
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.

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.
- AnIdiotOnTheNet 4y ago
  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.
  - iforgotpassword 4y ago
    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.
  - rfoo 4y ago
    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.

nineteen999 4y ago

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.