What does HackerNews think of glibc_version_header?

Build portable Linux binaries without using an ancient distro

Language: C++

Flatpak is not the future (2021) | Aug 2023
One major headache with trying to run precompiled binaries on Linux is that if they were compiled using a newer version of glibc than the target machine, they won't be able to run. Back while working on Factorio, I was trying to get around this problem with endless Docker containers, but coworker Wheybags came up with a much simpler solution to this, which is simply to, at compile time, link to the oldest compatible version of glibc by including a header: https://github.com/wheybags/glibc_version_header

It's too bad this hasn't been standard practice for the past 30 years!

Win32 Is the Only Stable ABI on Linux? | Aug 2022
Expand Context ↕
If what you're doing works for you, great, but in case it stops working at some point (or if for some reason you need to build on a current-gen distro version), you could also consider using this:

https://github.com/wheybags/glibc_version_header

It's a set of autogenerated headers that use symbol aliasing to allow you to build against your current version of glibc, but link to the proper older versioned symbols such that it will run on whatever oldest version of glibc you select.
The Windows malloc() implementation from MSVCRT is slow | Jul 2022
Expand Context ↕
This is the opposite problem of what's being talked about. Binaries built against old versions of glibc should run just fine against newer versions. This is about a binary built against a newer version of glibc that doesn't run on an older one. This is common, and super annoying. There are ways to build to eliminate this problem, but they all feel like hacks, or involve a lot of extra work.

(Hacks such as https://github.com/wheybags/glibc_version_header -- which apparently does work very well, but still feels like an annoying hoop that should be unnecessary to jump through. I wish glibc's shipped headers actually could support this out of the box so you could set a preprocessor define like `-DGLIBC_TARGET_ABI=2.12` and it would just work.)
Cross-compiling binaries for Windows is easier than building natively | Jun 2022
Expand Context ↕
There are other approaches like https://github.com/wheybags/glibc_version_header or sysroots with older glibc, e.g. https://wiki.gentoo.org/wiki/Crossdev - you don't need your whole XP, just the the system libs to link against.

Sure, having a nice SDK where you can just specify the minimum vesion you want to support would be nice but who do you expect to develop such an SDK? GNU/glibc maintainers? They would rather you ship as source. Red Hat / SUSE / Canonical? They want you to target only their distro. Valve? They decided its easier to just provide an unchaning set of libraries since they need to support existing games that got things wrong anyway and already have a distribution platform to distribute such a base system along with the games without bundling it into every single one.
Cross-compiling binaries for Windows is easier than building natively | Jun 2022
Expand Context ↕
> the closest I've seen to fixing this issue is https://github.com/wheybags/glibc_version_header

Or just compile against an older glibc version. Plenty of tools to setup sysroots for that, e.g. https://wiki.gentoo.org/wiki/Crossdev