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

[Sam James]

> On 1 Feb 2023, at 16:26, Florian Weimer <fweimer@redhat.com> 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.

From my side, the issue is that glibc has enabled something which is
technically necessary, but given no guidance. This enables people to
footgun (and there's a risk of e.g. Debian moving first on this, they're
very keen to) and cause problems for compatibility, at least for arm.)

I get your perspective and if the result from this is "let's wait 2 more
years and no general-purpose distributions should be making the switch",
then that's not a terrible outcome. But providing no guidance whatsoever
Is dangerous, I feel.

Even "wait until we figure this out" as guidance would be useful.

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

Right, my motivation is almost entirely old hardware on curren
distributions.

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

Yes, a lot of my concerns come from either modern or somewhat modern
Arm hardware.

I too am not very sympathetic to the desire to run 32-bit userland
If the hardware is capable and software can be rebuilt if it's for
resource reasons - they can use x32 if they insist.

(As an aside, I love - and agree - with the acknowledgement that
x32 is presently dead ;))

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

Agreed.

Then we're back to "how do we enable people to make the transition
where they have the freedom to rebuild userspace?"

If glibc didn't see the value in that at all, it shouldn't have added
the options. But the options are there, they're in the wild,
and they're documented. So people have, are, and are going to
try to use them.

Then we're back to:
1. How do we stop people doing it dangerously?

2. How do we enable distributions interested in supporting
cases where the hardware only works for 32-bit & they can
rebuild their userland in its entirety?

If we don't want to do 2. yet, then we need to figure out
something for 1. Saying "wait because there aren't
the resources to make the migration sane yet" would
work.

Best,
sam

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 358 bytes
Desc: Message signed with OpenPGP
URL: <https://sourceware.org/pipermail/libc-alpha/attachments/20230201/b9a10e1e/attachment-0001.sig>