5 ms·

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 every

by 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.

by rfoo 4y ago

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.