4 ms·

This is a big forwards-compatibility risk. Suppose glibc adds a new symbol, and then a GPU driver adds a dependency on that symbol. The user wants to run an o

by comex 1mo ago

This is a big forwards-compatibility risk. Suppose glibc adds a new symbol, and then a GPU driver adds a dependency on that symbol. The user wants to run an old executable with the updated GPU driver (maybe the old GPU driver doesn’t support their GPU). Normally, this would work fine: the user has to use a new copy of glibc, which will be compatible with both the new GPU driver and the old executable. But with your approach, the GPU driver is forced to use the glibc reimplementation which has been statically linked into the executable. Which, since the executable is old, can’t possibly implement the new symbol. The same issue would occur if glibc adds a new version of an existing symbol and then the GPU driver is recompiled. (Or, for that matter, if a GPU driver adds a dependency on a symbol which glibc has always supported but which isn’t in the subset that you reimplemented, though in theory that could be solved if you reimplemented 100% of the symbols.)

account42 1mo ago
Yes this is just asking for trouble - and all it does is solve a problem that doesn't really exist. Just dynamically link against the oldest glibc you want to support. Its annoying that Linux toolchains don't have built in easy mode support for that but its much easier to deal with than this thing will be when it breaks. It's also not just new symbols, the loader semantics also aren't static and new enough libraries may not support older semantics - e.g. the loader used to use DT_HASH entries for symbol resolution but now they are no longer present on all distributions.
- yxhuvud 1mo ago
  This is not a desirable solution on musl based systems. Whatever you do in that situation ends up horrible, so it is about finding the least bad solution. Which this seems like a workable variant of.
- egorfine 1mo ago
  > Just dynamically link against the oldest glibc you want to support I wish it would that simple for practical use cases. I ship professional software for colorists for Hollywood studios and they absolutely love to never upgrade. We have to ship for RockyLinux 8. Sad.
  - eoanermine 1mo ago
    RockyLinux doesn't sound so bad. It's not even EOL.
    - egorfine 1mo ago
      It's just this short of being EOL.
      - duskdozer 1mo ago
        Almost three years? >Rocky Linux 8 is supported by the Rocky Linux project until May 2029. https://forums.rockylinux.org/t/what-is-eol-of-rl8/3316/3 https://forums.rockylinux.org/t/what-is-eol-of-rl8/3316/3
        egorfine 1mo ago
        Yes but only the very last version and only paid support. Don't mind to pay, it's just that no amount of payment would be a proper solution to ancient environment with everything.
    - coredog64 1mo ago
      We still have RHEL7 hosts in production. Every day it gets harder to find packages with a glibc 2.17 floor.
      - danudey 1mo ago
        (I'm certain you know this already but I'm posting this for people who might want more context) Part of the problem that people don't really realize is that it's not practical to just 'link against old glibc'. In order to ensure compatibility with RHEL7 we need to link against RHEL7 libraries, which means we need to build on RHEL7. That means old, unpatched versions of glibc, libpcap, libcurl, openssl, or who knows what else, in case there's some backwards-incompatible change in newer RHEL versions. Alternately, we can build/patch the libraries we use and compile them statically into the binary, which is vastly more maintenance work for us for very little benefit. Meanwhile, compiling against older versions of libraries like glibc means we don't get the benefit of updates; not just new features in glibc, but things like more/better SIMD support in glibc algorithms, more/better optimizations in GCC, and so on. Alternately, we can stop supporting RHEL7, like Redhat did, and build against RHEL8... Or we can build a separate version against each version of RHEL we want to support. Funnily enough, we've been shipping RHEL7 RPMs of our product for years, and only recently realized that they won't actually run on RHEL7 because at some point the toolchain updated and now we're compiling against too new of a glibc version and then packaging it into a RHEL7 RPM. It wouldn't have worked on RHEL <8 for the past... few years? But no one uses RHEL7 so it went completely untested for ages and we didn't get any customer complaints. Now we're re-labelling our RPMs as EL8, but it's just a cosmetic change so that we're claiming the version that we actually require.
- throwaway2046 1mo ago
  > Just dynamically link against the oldest glibc you want to support. Just the other day I tried running an older binary and it failed with a glibc error, despite it being linked to a glibc version that's barely 5 releases behind the one on my system. So maybe glibc isn't backwards compatible after all...
  - account42 1mo ago
    Or maybe you misunderstood the error message.
    - pg83 1mo ago
      Or may be not.
pg83 1mo ago
This means the user will update the binary with my program and continue using it happily. I'm not offering a silver bullet, but the approach I've implemented is much better than what the industry currently offers.
- cryptonector 1mo ago
  Exactly. I think you're doing fine. It's weird that you're using C++ here, since that brings in a lot of crap, but then your programs are probably C++ anyway, so it's not a problem. Honestly I'm impressed by this work. It's a thankless thing to have built, it's definitely feasible to build but more work than almost anyone would have been willing to do. What would be even neater is if Musl had this builtin.

by comex 1mo ago

account42 1mo ago

Yes this is just asking for trouble - and all it does is solve a problem that doesn't really exist. Just dynamically link against the oldest glibc you want to support. Its annoying that Linux toolchains don't have built in easy mode support for that but its much easier to deal with than this thing will be when it breaks. It's also not just new symbols, the loader semantics also aren't static and new enough libraries may not support older semantics - e.g. the loader used to use DT_HASH entries for symbol resolution but now they are no longer present on all distributions.

yxhuvud 1mo ago
This is not a desirable solution on musl based systems. Whatever you do in that situation ends up horrible, so it is about finding the least bad solution. Which this seems like a workable variant of.
egorfine 1mo ago
> Just dynamically link against the oldest glibc you want to support I wish it would that simple for practical use cases. I ship professional software for colorists for Hollywood studios and they absolutely love to never upgrade. We have to ship for RockyLinux 8. Sad.
- eoanermine 1mo ago
  RockyLinux doesn't sound so bad. It's not even EOL.
  - egorfine 1mo ago
    It's just this short of being EOL.
    - duskdozer 1mo ago
      Almost three years? >Rocky Linux 8 is supported by the Rocky Linux project until May 2029. https://forums.rockylinux.org/t/what-is-eol-of-rl8/3316/3 https://forums.rockylinux.org/t/what-is-eol-of-rl8/3316/3
      - egorfine 1mo ago
        Yes but only the very last version and only paid support. Don't mind to pay, it's just that no amount of payment would be a proper solution to ancient environment with everything.
  - coredog64 1mo ago
    We still have RHEL7 hosts in production. Every day it gets harder to find packages with a glibc 2.17 floor.
    - danudey 1mo ago
      (I'm certain you know this already but I'm posting this for people who might want more context) Part of the problem that people don't really realize is that it's not practical to just 'link against old glibc'. In order to ensure compatibility with RHEL7 we need to link against RHEL7 libraries, which means we need to build on RHEL7. That means old, unpatched versions of glibc, libpcap, libcurl, openssl, or who knows what else, in case there's some backwards-incompatible change in newer RHEL versions. Alternately, we can build/patch the libraries we use and compile them statically into the binary, which is vastly more maintenance work for us for very little benefit. Meanwhile, compiling against older versions of libraries like glibc means we don't get the benefit of updates; not just new features in glibc, but things like more/better SIMD support in glibc algorithms, more/better optimizations in GCC, and so on. Alternately, we can stop supporting RHEL7, like Redhat did, and build against RHEL8... Or we can build a separate version against each version of RHEL we want to support. Funnily enough, we've been shipping RHEL7 RPMs of our product for years, and only recently realized that they won't actually run on RHEL7 because at some point the toolchain updated and now we're compiling against too new of a glibc version and then packaging it into a RHEL7 RPM. It wouldn't have worked on RHEL <8 for the past... few years? But no one uses RHEL7 so it went completely untested for ages and we didn't get any customer complaints. Now we're re-labelling our RPMs as EL8, but it's just a cosmetic change so that we're claiming the version that we actually require.
throwaway2046 1mo ago
> Just dynamically link against the oldest glibc you want to support. Just the other day I tried running an older binary and it failed with a glibc error, despite it being linked to a glibc version that's barely 5 releases behind the one on my system. So maybe glibc isn't backwards compatible after all...
- account42 1mo ago
  Or maybe you misunderstood the error message.
  - pg83 1mo ago
    Or may be not.

pg83 1mo ago

This means the user will update the binary with my program and continue using it happily. I'm not offering a silver bullet, but the approach I've implemented is much better than what the industry currently offers.

cryptonector 1mo ago
Exactly. I think you're doing fine. It's weird that you're using C++ here, since that brings in a lot of crap, but then your programs are probably C++ anyway, so it's not a problem. Honestly I'm impressed by this work. It's a thankless thing to have built, it's definitely feasible to build but more work than almost anyone would have been willing to do. What would be even neater is if Musl had this builtin.