Re: time64 functions for glibc

[Adhemerval Zanella <adhemerval.zanella@linaro.org>]

On 31/05/2021 16:16, Florian Weimer wrote:
> * Adhemerval Zanella:
> 
>> We either make it default for all affected architectures or we should
>> keep as is, I see not point in making it architecture dependent.
> 
> I'm under the impression that 32-bit Arm is sufficiently different.

It might make sense on how a distribution is build and deployed, but I
think from glibc point is view regarding LFS and 64 bit time_t support
they should be handled the same.

> 
>> And I don't see your point here: if the legacy is being recompiled
>> it is in essence not in compatibility mode.  We really need to move
>> from non-LFS and 32-bit time_t interfaces.
> 
> It's about providing a stack of 32-bit libraries for use by legacy
> applications.  These libraries are rebuilt from time to time by
> distributions and would pick up the changed default, therefore becoming
> incompatible with legacy applications.  Development work is required to
> support both ABIs in one installation.  If no one is willing to do the
> work (which is what I expect for most of the relevant libraries), for
> i386 the more useful choice is the current ABI, to support legacy
> applications that can't be recompiled.

I don't have a good answer for case where the libraries uses time_t
and related types on their own ABI, it would indeed require some
work.  But at same time if they are bounded by this, these very
libraries and application will most likely run in trouble eventually 
due y2038.

I already heard some issue regarding LFS support in the wild, autoconf 
and other configuration system tries hard to make is default but even
then there are cases where they are not used (the BZ#23960 for instance).

So I still think making *better* defaults, even if it requires some work
from consumers, is better than keep ABIs with either underlying issues or
inherent faulty support.