3 ms·

Glibc has a terrible history of binary incompatibility. If that's so hard to believe, try running binaries built on one distribution on other distributions. Lin

by pg83 2mo ago

Glibc has a terrible history of binary incompatibility. If that's so hard to believe, try running binaries built on one distribution on other distributions. Linux has two stable ABIs: the kernel ABI for static programs, and, ironically, WINE.

vlovich123 2mo ago
I haven’t heard of this and I don’t think you’re right. Glibc, for all its faults, as a general rule does backward compatibility well. The problem is if you compile against a newer glibc (common in CI by default) and try to run on a distro with an older (common in the wild). If your CI uses an older glibc you should be fine AFAIK.
- pg83 2mo ago
  https://bugzilla.redhat.com/show_bug.cgi?id=638477 https://bugzilla.redhat.com/show_bug.cgi?id=638477 is the most "famous" example. There are also much less well-known "little things" that regularly pop up here and there. > If your CI uses an older glibc you should be fine AFAIK. In any case, my binaries work not only under glibc, but also under Alpine, and (work in progress) under android/bionic.
  - vlovich123 2mo ago
    Not sure what you’re trying to show with that bug report but it’s not a case of cross distro glibc issues. If I read correctly it’s a vanilla behavioral change that exposed preexisting UB in flash. Not sure how the comments about alpine or bionic relate either to my claim that cross distro glibc is fine.
    - pg83 2mo ago
      It depends on how we define the ABI. I see it as a set of client-visible invariants that they rely on. In my world, glibc changed the client's visible invariants, breaking the client. The client works on one glibc-based host, but not on another. What is this if not "a case of cross-distro glibc issues?" Overall, both of our points of view on compatibility were discussed well in that thread; we probably shouldn't repeat ourselves. :)
      - account42 2mo ago
        ABI is not "whatever happens to work with this distro" but "what programs that comply with the API contract compile to". Overlapping memcpy arguments is an API contract violation and thus not something covered by the ABI either. This distinction is the entire reason why C has a separate memmove function. You can't just make up your own imaginary ABI contract and then blame the system when it doesn't fulfill it. That's going to result in self-inflicted plain on any OS.
        pg83 2mo ago
        It's so good that Linus thinks differently!
        ninkendo 2mo ago
        Even Linus’s comments in that bug hedge things a bit: > and that if people depend on interfaces we exported having side effects that weren't intentional, we try to fix things so that they still work unless there is a major reason not to. (Emphasis mine.) In the Flash case, they changed the direction memcpy works in, in a way that didn’t actually improve any performance (Linus did benchmarks to show it) and Linus’s point was that there’s no upside to the change, and only downsides, so on the whole it makes no sense to keep the changed memcpy. You could imagine plenty of scenarios where existing behavior truly is broken, and show that no popular software depends on the brokenness (which is why distros are in a great place to do these kinds of smoke tests, they have thousands of packages they can test), and make a judgement call. A “zero regressions no matter what” policy is impossible in practice due to Hyrum’s law, at some point you have to use common sense and draw the line somewhere sensible.
      - ninkendo 2mo ago
        > It depends on how we define the ABI. I see it as a set of client-visible invariants that they rely on By that definition, any change of any kind will break ABI, Hyrum’s law and spacebar heating and all that.
      - vlovich123 2mo ago
  - __turbobrew__ 2mo ago
    > Quite frankly, I find your attitude to be annoying and downright stupid. - Linus Torvalds That bug report was a good read.
diabllicseagull 2mo ago
according to appimage recommendations as long as you build against glibc with an earlier version than the system it's run on it should be fine. https://docs.appimage.org/reference/best-practices.html https://docs.appimage.org/reference/best-practices.html I hear you about WINE though.
- Natalia724 2mo ago
  [flagged]
- deleted 2mo ago
  [deleted]
jezek2 2mo ago
This is not true. Glibc supports symbol versioning. You can use it to select old versions of used symbols. The result is a binary that can work on 20 year old distros the same as on the latest, compiled with latest compiler and Glibc. You can also compile using old distro and old Glibc to get similar effect. Though you would miss the advances of the newer compilers.
- pg83 2mo ago
  https://news.ycombinator.com/item?id=49358538 https://news.ycombinator.com/item?id=49358538
cryptonector 2mo ago
That irony is delicious. Build to WIN32 APIs to ship on Linux.

by pg83 2mo ago

vlovich123 2mo ago

I haven’t heard of this and I don’t think you’re right. Glibc, for all its faults, as a general rule does backward compatibility well. The problem is if you compile against a newer glibc (common in CI by default) and try to run on a distro with an older (common in the wild). If your CI uses an older glibc you should be fine AFAIK.

pg83 2mo ago
https://bugzilla.redhat.com/show_bug.cgi?id=638477 https://bugzilla.redhat.com/show_bug.cgi?id=638477 is the most "famous" example. There are also much less well-known "little things" that regularly pop up here and there. > If your CI uses an older glibc you should be fine AFAIK. In any case, my binaries work not only under glibc, but also under Alpine, and (work in progress) under android/bionic.
- vlovich123 2mo ago
  Not sure what you’re trying to show with that bug report but it’s not a case of cross distro glibc issues. If I read correctly it’s a vanilla behavioral change that exposed preexisting UB in flash. Not sure how the comments about alpine or bionic relate either to my claim that cross distro glibc is fine.
  - pg83 2mo ago
    It depends on how we define the ABI. I see it as a set of client-visible invariants that they rely on. In my world, glibc changed the client's visible invariants, breaking the client. The client works on one glibc-based host, but not on another. What is this if not "a case of cross-distro glibc issues?" Overall, both of our points of view on compatibility were discussed well in that thread; we probably shouldn't repeat ourselves. :)
    - account42 2mo ago
      ABI is not "whatever happens to work with this distro" but "what programs that comply with the API contract compile to". Overlapping memcpy arguments is an API contract violation and thus not something covered by the ABI either. This distinction is the entire reason why C has a separate memmove function. You can't just make up your own imaginary ABI contract and then blame the system when it doesn't fulfill it. That's going to result in self-inflicted plain on any OS.
      - pg83 2mo ago
        It's so good that Linus thinks differently!
        ninkendo 2mo ago
        Even Linus’s comments in that bug hedge things a bit: > and that if people depend on interfaces we exported having side effects that weren't intentional, we try to fix things so that they still work unless there is a major reason not to. (Emphasis mine.) In the Flash case, they changed the direction memcpy works in, in a way that didn’t actually improve any performance (Linus did benchmarks to show it) and Linus’s point was that there’s no upside to the change, and only downsides, so on the whole it makes no sense to keep the changed memcpy. You could imagine plenty of scenarios where existing behavior truly is broken, and show that no popular software depends on the brokenness (which is why distros are in a great place to do these kinds of smoke tests, they have thousands of packages they can test), and make a judgement call. A “zero regressions no matter what” policy is impossible in practice due to Hyrum’s law, at some point you have to use common sense and draw the line somewhere sensible.
    - ninkendo 2mo ago
      > It depends on how we define the ABI. I see it as a set of client-visible invariants that they rely on By that definition, any change of any kind will break ABI, Hyrum’s law and spacebar heating and all that.
    - vlovich123 2mo ago
- __turbobrew__ 2mo ago
  > Quite frankly, I find your attitude to be annoying and downright stupid. - Linus Torvalds That bug report was a good read.

diabllicseagull 2mo ago

according to appimage recommendations as long as you build against glibc with an earlier version than the system it's run on it should be fine. https://docs.appimage.org/reference/best-practices.html https://docs.appimage.org/reference/best-practices.html I hear you about WINE though.

Natalia724 2mo ago
[flagged]
deleted 2mo ago
[deleted]

jezek2 2mo ago

This is not true. Glibc supports symbol versioning. You can use it to select old versions of used symbols. The result is a binary that can work on 20 year old distros the same as on the latest, compiled with latest compiler and Glibc. You can also compile using old distro and old Glibc to get similar effect. Though you would miss the advances of the newer compilers.

pg83 2mo ago
https://news.ycombinator.com/item?id=49358538 https://news.ycombinator.com/item?id=49358538

cryptonector 2mo ago

That irony is delicious. Build to WIN32 APIs to ship on Linux.