On Thu, 2 Feb 2023 at 05:27, Florian Weimer via Libc-alpha <
libc-alpha@sourceware.org> wrote:

> * Sam James via Libc-alpha:
>
> > Right, it seems RH has some needs due to supporting existing
> > customers, but I don't think this should unduly affect what glibc
> > upstream does if there's one clear technical path forward. Nobody
> > seems to actually dispute that the end-game here is a hard switch at
> > some point. Just about when.
>
> I'm mostly worried about the glibc project issuing a statement that
> distributions should change the i386 ABI of libraries layered on top of
> glibc.  I don't quite see how this is in anyone's interest.
>
> What's the reason for a 32-bit x86 distribution at this point?  Support
> for old hardware which can't run 64-bit binaries?  Running 32-bit
> binaries which can't be rebuilt?  Optimizing the footprint of workloads
> that fit into a 32-bit address space?
>

The only reason Ubuntu still builds any packages on i386 at all is reason 2
here, to allow people to run old binaries that can't be rebuilt. As time
passes the binaries that people care about are increasingly games. I
presume for the cases where y2038 matters the default solution will be to
run these binaries in a namespace that lies about the time.

Only the first reason (old hardware on current distributions) can
> justify the ABI bump.  And it's in direct conflict with the second
> reason.
>

Exactly.


> For the third reason, it may be more approriate to revive the x32 port.
> At least it doesn't interfere with legacy use.  There's a non-upstream
> ILP32 port for aarch64, too, so the largely the same choice is available
> over there (although 32-bit-only CPUs that may run glibc code are still
> being manufactured in the Arm ecosystem, so the tradeoffs are different
> over there, I assume).
>

The 32-bit arm would is an entirely different calculation, yes. There are
definitely devices being manufactured today that run Linux 32-bit that have
the sort of expected lifetime that will bump into y2038 issues. I really
hope the manufacturers have a plan! OTOH, there isn't a large pile of old
armhf binaries lying around that people want to keep working in the same
way there is on x86.

For people who use yocto or buildroot they should just start passing
-D_TIME_BITS=64 and rebuild the world but general purpose, package based
distributions have a more delicate dance to perform (FWIW, we don't have a
fully fledged plan for Ubuntu yet but we're certainly starting to think
about it).


> My hunch is that the most likely outcome of switching distributions to
> 64-bit time_t is that the i386 port goes away more quickly than I would
> expect otherwise because it makes the port rather useless for most
> existing users (especially with those distributions that no longer
> maintain a 32-bit-only kernel).  Personally, that wouldn't be a bad
> outcome at all for me.  But I doubt that this is what people who push
> for this change have in mind.
>

Is anyone proposing that glibc will lose the ability to have the 32-bit
time_t ABI? As you note that would kill the Ubuntu i386 port entirely (at
some point this will probably happen anyway, people can always play their
games in VMs but still).

Cheers,
mwh