3 ms·

Setting up a machine or build system for older glibc is not trivial . If you know of any DISTRO which allows you to downgrade glibc out of the box please let me

Setting up a machine or build system for older glibc is not trivial . If you know of any DISTRO which allows you to downgrade glibc out of the box please let me know. Keep in mind that if you go back enough you will also have trouble with kernel headers and compiler interactions. Even in yocto which is a build system that builds custom distributions from scratch does not have a great experience for different glibc versions than what is shipped. Have a look at the nightmare recipes for libc. On the other hand they do provide the basics of how to ship a custom libc loader across heterogeneous machines but it gets complicated fast and not something any non specialist can do in an hour. In my experience anybody saying to compile statically does not know about the libc limitations. When they find them they hand wave, I smile and say be my guest. By the way 2.17 is an appropriate version to target. RHEL6 much? :D

dgrunwald 2y ago
You don't need a distro with ancient glibc; you can instead create a cross-compilation toolchain. We used https://crosstool-ng.github.io/docs/ https://crosstool-ng.github.io/docs/ to create a cross-compilation toolchain that runs on modern debian, but produces executables that only need glibc 2.17. The only downside is that you no longer can simply apt-get a library you need -- all dependencies shipped along with your application also need to be built with this cross-compiler.
forrestthewoods 2y ago
> Setting up a machine or build system for older glibc is not trivial . God, I hate glibc so much. It’s an absolutely terrible design from the 80s. It can and should be trivial to target any arbitrary version of glibc. The way Linux performs linking is so bad and so much worse than Windows. (Headers + thin import lib. Linking expecting a full and complete so is stupid and bad.) Zig solved this problem. It can trivially target any version of glibc and cross-compile. It’d be nice if the Linux community demanded this level of functionality from their toolchains. Alas. https://andrewkelley.me/post/zig-cc-powerful-drop-in-replacement-gcc-clang.html https://andrewkelley.me/post/zig-cc-powerful-drop-in-replace...
- glandium 2y ago
  Linking does not expect a full and complete so. That's what it's currently fed, but it's not a requirement. You could just as well have "import libs" in ELF too.
  - forrestthewoods 2y ago
    Neither GCC nor Clang produce "import libs" on Linux. The entire ecosystem is built around linking whatever full .so happen to be in the global search path. What Zig does is goes way way way out of it's way to compile import libs which contains all of the exported functions but the implementations are empty. So you aren't wrong. But the point is that the monumentally large Linux ecosystem does not work that way. Which is a real shame.
ogurechny 2y ago
RHEL 7 (Centos 7) still has 5 days before end of support. You can get recent gcc with official developer environment update to deal with new code. Whoosh, 10 years of API compatibility suitable even for corporate environments. Of course, new code may actually need features from newer libc, and often you won't be able to frankenstein your way out of it with no-op plug functions and copypasting successfully. There's also a random page on the internet with a barebones cross-distribution compatibility guide: https://gist.github.com/wagenet/35adca1a032cec2999d47b6c40aa45b1 https://gist.github.com/wagenet/35adca1a032cec2999d47b6c40aa... In general, “community support” shrinks to “ride on what Red Hat provides”.
GoblinSlayer 2y ago
From the linker viewpoint glibc is four files on disk. You can have them in ~/.local/glibc FWIW, linker doesn't care. I imagine it should be enough to download libc-dev package and unpack it in ~/.local/glibc The actual dependency is 2.14, when a faster memcpy was added, 2.17 is just whatever I happened to have around back when I compiled my stuff, I just didn't change anything since then, bits don't rot.

dgrunwald 2y ago

You don't need a distro with ancient glibc; you can instead create a cross-compilation toolchain. We used https://crosstool-ng.github.io/docs/ https://crosstool-ng.github.io/docs/ to create a cross-compilation toolchain that runs on modern debian, but produces executables that only need glibc 2.17. The only downside is that you no longer can simply apt-get a library you need -- all dependencies shipped along with your application also need to be built with this cross-compiler.

forrestthewoods 2y ago

> Setting up a machine or build system for older glibc is not trivial . God, I hate glibc so much. It’s an absolutely terrible design from the 80s. It can and should be trivial to target any arbitrary version of glibc. The way Linux performs linking is so bad and so much worse than Windows. (Headers + thin import lib. Linking expecting a full and complete so is stupid and bad.) Zig solved this problem. It can trivially target any version of glibc and cross-compile. It’d be nice if the Linux community demanded this level of functionality from their toolchains. Alas. https://andrewkelley.me/post/zig-cc-powerful-drop-in-replacement-gcc-clang.html https://andrewkelley.me/post/zig-cc-powerful-drop-in-replace...

glandium 2y ago
Linking does not expect a full and complete so. That's what it's currently fed, but it's not a requirement. You could just as well have "import libs" in ELF too.
- forrestthewoods 2y ago
  Neither GCC nor Clang produce "import libs" on Linux. The entire ecosystem is built around linking whatever full .so happen to be in the global search path. What Zig does is goes way way way out of it's way to compile import libs which contains all of the exported functions but the implementations are empty. So you aren't wrong. But the point is that the monumentally large Linux ecosystem does not work that way. Which is a real shame.

ogurechny 2y ago

RHEL 7 (Centos 7) still has 5 days before end of support. You can get recent gcc with official developer environment update to deal with new code. Whoosh, 10 years of API compatibility suitable even for corporate environments. Of course, new code may actually need features from newer libc, and often you won't be able to frankenstein your way out of it with no-op plug functions and copypasting successfully. There's also a random page on the internet with a barebones cross-distribution compatibility guide: https://gist.github.com/wagenet/35adca1a032cec2999d47b6c40aa45b1 https://gist.github.com/wagenet/35adca1a032cec2999d47b6c40aa... In general, “community support” shrinks to “ride on what Red Hat provides”.

GoblinSlayer 2y ago

From the linker viewpoint glibc is four files on disk. You can have them in ~/.local/glibc FWIW, linker doesn't care. I imagine it should be enough to download libc-dev package and unpack it in ~/.local/glibc The actual dependency is 2.14, when a faster memcpy was added, 2.17 is just whatever I happened to have around back when I compiled my stuff, I just didn't change anything since then, bits don't rot.