Hi! On Sun, 2024-03-31 at 06:54:10 +0200, Andreas Metzler wrote: > On 2024-03-30 Julian Gilbey <jul...@d-and-j.net> wrote: > > My very limited understanding of this major transition was that the > > t64 libraries are being held in unstable until (almost) everything is > > ready, at which point there will be a coordinated migration into > > testing. But I've now been asked to upgrade something on my testing > > machine which pulls in a t64 library. Has something slipped through > > the net, or is this intentional? > > > Looking through testing, I see the following t64 libraries present: > > > libaio1t64 > > I also stumbled over libaio1t64 and looked at the changelog. It is not > part of the transition in that it was simply rebuilt with different > compiler flags and therefore broke the ABI. Instead source code changes > were made to extend the ABI to support usage both from code built with > t64 flags and without.
Right, for libaio this is intentional. The changes were made to avoid breaking the ABI (so as you say, implement dual ABI) because the library uses direct syscalls so simply rebuilding with new flags would have broken the ABI, although the actual SONAME change did then break the ABI :), and it was done to avoid stomping over upstream interfaces. Once I've looked into fixing Linux, I'll be submitting this upstream with the hope that I can revert the SONAME change with backwards compatibility symlink and package rename. This also brings something I mentioned to Steve, but which I'm not sure has been acted on. We need to check for all affected libraries and whether they are using direct syscalls, because then if they do not have explicit support for the equivalent 64-bit variants of those syscalls, a simple rebuild of those libraries might actually have broken the ABI between userland and kernel for those transitioned packages. I had a list of the potentially affected syscalls, but need to run out now, will try to post something better later today. Thanks, Guillem
