time64 / Large File Support: 2) default time64 breaks legacy 32bit binaries

[Florian Weimer]

* 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?

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

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).

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.

Thanks,
Florian