Re: Y2038 - best way forward in Debian?
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
Reply to: