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

[Florian Weimer <fweimer@redhat.com>]

* Sam James via Libc-alpha:

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

I can try to write a patch to amend the old NEWS entry.

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

It depends on whether these people want to do actual work.

The full rebuild solves only some of the issues.

For example, we didn't add a __dlsym_time64 alias, so each time some FFI
(think Python ctypes, but pretty much anything that doesn't use the C
headers in the intended way) looks up “gettimeofday”, they get the
32-bit version.  This issue won't go away with a rebuild.  It will still
be there as long as the rebuild uses the standard i386 ABI, even if we
add a configure switch that enables 64-bit time_t by default and glibc
is built using this switch.  Maybe we can patch things up upstream so
that it is possible to build with

DEFAULT GLIBC_2.34

in sysdeps/unix/sysv/linux/i386/shlib-versions and the time32 interfaces
are just gone.  But that results in a really non-standard ABI.

> One more thing: I'm fine with us saying to wait, because
> ideally we'd be done (lol) with Modern C porting first,
> because implicit function declarations affect doing mass-
> rebuilds anyway if someone is doing this via the package
> manager rather than hard-changing the glibc default.

You are right, there is a definite connection here: if you call any of
the time64 functions through an implicit declaration, you won't get the
64-bit redirects, either.  It's similar to the dlsym problem.

Thanks,
Florian