4 ms·

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

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.

rini17 2y ago
Everything is fine until it isn't when you run into mismatch like 64bit file offsets and time_t.
- jchw 2y ago
  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.
  - rini17 2y ago
    So this is non issue you say? https://blogs.gentoo.org/mgorny/2024/09/28/the-perils-of-transition-to-64-bit-time_t/ https://blogs.gentoo.org/mgorny/2024/09/28/the-perils-of-tra...
    - jchw 2y ago
      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.

rini17 2y ago

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

jchw 2y ago
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.
- rini17 2y ago
  So this is non issue you say? https://blogs.gentoo.org/mgorny/2024/09/28/the-perils-of-transition-to-64-bit-time_t/ https://blogs.gentoo.org/mgorny/2024/09/28/the-perils-of-tra...
  - jchw 2y ago
    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.