On Wed, 2020-02-05 at 15:35:28 +0100, Ansgar wrote: > On Wed, 2020-02-05 at 08:33 -0500, Sam Hartman wrote: > > Steve, you're presuming that we would not create a new soname for > > libc6 on architectures where we want a new time ABI. > > Isn't the libc ABI for some reason part of Debian's architecture name? > uclibc-linux-amd64, musl-linux-i386, i386 are distict architectures > after all. So an incompatible newglibc-linux-i386 would be different > from i386 as well?
Each libc needs its own architecture as that requires its own matching C compiler, for the libc CRT, ld.so linker, some parts of the calling convention, data types, or executable format ABI, etc. This is one side of the architecture ABI, the other is coming from the CPU and kernel ABIs, for example. Given our current usage and definition of Debian architectures and mapping to GNU triplets, the libc4 to libc5 (+ a.out to ELF migration), or the libc5 to libc6 might have indeed demanded a new arch, as these required new compilers (or a least different spec files) AFAIR and some kind of hacked triplet-qualified hierarchies, but back then our requirements for architecture definitions seems to have been more primitive (first mostly mapping between CPU names, then CPU + kernel names), we didn't have multiarch, and I guess a new arch (if it was even considered, probably not) would have been deemed a cost too high, and direct upgradability was probably way more important at the time. Also the ABI tracked by the libc SONAME is a different part, and that should not necessarily require a different compiler, otherwise you could not build binaries against different SOVERSIONs for the same libc. I suppose the problem here is that the C compiler and C library are both in charge of defining part of the architecture ABI, but at the same time the C compiler and C library both also provide a set of shared libraries with their own specific ABIs, so this all gets muddled into the same basket. Thanks, Guillem
