Hacker News Reader

Comment by jchw | Hacker News Reader

Is libc updates really the primary problem with the ABI breaks on Linux? Glibc isn't perfect but it has versioned symbols going back a long time now. My guess would be the problem is actually abandoned versions of other libraries (e.g. SDL1, old versions of gtk2?) and maybe a handful of other things.

View on HN

Yeah, glibc is extremely stable and you can be sure that an app compiled against it now will work well into the future. People just completely ignore that fact based on hearsay, and that the removal of a unused symbol hashing table from the glibc binary broke a few anticheat systems that were attempting to parse it.

Other libraries are the problem, usually. People are generally really good about changing the .so version of a library when the ABI changes in a backwards-incompatible way. Usually distributions ship both versions until everything they ship either has upgraded or been removed. Solutions like appimage can allow you to ship these libraries in your app.

Everything is fine until it isn't when you run into mismatch like 64bit file offsets and time_t.

Good news if you're serious: You can now have a single glibc that supports programs compiled with and without -D_FILE_OFFSET_BITS=64 -D_TIME_BITS=64.

So this is non issue you say?

https://blogs.gentoo.org/mgorny/2024/09/28/the-perils-of-tra...

No, not at all, but that's a different problem. That issue is about linkage between two different binaries that have _TIME_BITS=32 and _TIME_BITS=64, not an issue with linking to glibc. However, that's only an issue when you are dealing with software that passes time_t in the ABI. Of course, on the whole, a distribution has to deal with all kinds of weirdly-intermingled and low-level packages, so this does happen a very non-trivial amount of times surely, but in general I expect that a lot of old binary software will be alright. You'd only run into this particular problem if you had an old binary that interfaced with another library that is provided by the system that did this. I didn't check, but I'd be quite surprised to find random time_t in most popular library APIs, e.g. I don't expect to see this in SDL or GTK.

Of course, if you did need to support this case, you don't need to throw the baby out with the bathwater necessarily. You'd just need a _TIME_BITS=32 build of whatever libraries do have time_ts in their ABI, and if that blog post is any indication Gentoo will probably have a solution for that in the future. I like the idea of jamming more backwards-compatibility work into the system dynamic linker. I think we should do more of that.

In any case, this issue is not a case where glibc broke something, it's a case where the ABI had to break. I understand that may seem like nitpicking, but on the other hand, consider what happens in 2038: All of the old binary software that relies on time_t being 32-bit will stop working properly even if you do have 32-bit time_t shims, at which point you'll need dirtier and likely less effective hacks if you want to be able to keep said software functioning.

The problem is backwards compatibility.

Someone comes along and builds their software on the latest bleeding-edge Linux distro. It won't run on older (or even many current) Linux desktops. People curse Linux ABI instability because new binaries aren't supported by an older operating system. It is in fact the opposite to the Windows situation, in which older software continues to run on newer operating systems, but good luck getting the latest Windows software to run on a Windows 95 desktop. People are very quick to conflate the two situations so they can score more fake internet points.

The situation is not limited to desktops. For example, a very popular commercial source forge web service does not work on browsers released more than about 10 weeks ago. The web itself has become fantastically unstable and almost unusable for anything except AI bots consuming what other AI bots spew.

Reply on news.ycombinator.com