https://bugzilla.redhat.com/show_bug.cgi?id=638477 is the most "famous" example.
replyThere 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.
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.
replyNot sure how the comments about alpine or bionic relate either to my claim that cross distro glibc is fine.
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?"
replyOverall, both of our points of view on compatibility were discussed well in that thread; we probably shouldn't repeat ourselves. :)
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.
replyIt's so good that Linus thinks differently!
reply> It depends on how we define the ABI. I see it as a set of client-visible invariants that they rely on
replyBy that definition, any change of any kind will break ABI, Hyrum’s law and spacebar heating and all that.
> Quite frankly, I find your attitude to be annoying and downright stupid.
reply- Linus Torvalds
That bug report was a good read.