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

[Florian Weimer]

* Adhemerval Zanella Netto:

> It is an option, although I am not sure what might really work since afaik
> Linux does not support CLOCK_REALTIME on time namespace.

Not yet.  The pressure isn't there yet, but I totally see it happening.

> Not really, there are some idea on how to proceed with 64 time_t promotion:
> 
>   1. Add a configure option to enable LFS and 64 bit time_t support as default.
>      It is basically promoting the port to a new ABI, although a program can
>      still build with non LFS or 32 bit time_t by explicit use -D_TIME_BITS=32.
> 
>   2. Make this option the default on a future glibc version, meaning that for 
>      distribution that want to keep the the compatibility mode as default (to
>      run old binaries) will need to explicit enable it.
> 
>   3. Move the non-LFS and 32 bit time_t symbols compat one, meaning that newer
>      binaries won't be able to use them and -D_TIME_BITS=32 won't be supported
>      or just be a no-op.
> 
> The 1 and 2 should not be cause many trouble, even if 2 would make
> 32-bit time_t opt-in.  At least it would focused on glibc itself,
> meaning that a distribution could just ignore the transition by just
> adding a configure option on glibc build.

I tend to agree, except we'd have to make it clear that 1 (if enabled)
& 2 may require extensive porting work across the distribution to
maintain a consistent ABI.

> The 3. is what might cause i386 (and any 32-bit port where ABI also supports
> 64-bit) to wither.  I don't have a strong opinion, maybe we should focus on
> only the 1. and 2. and see what community things about 3.

This still doesn't solve the implicit function declaration/dlsym
problem, though, so I don't know how

Meanwhile, Ocaml has removed compiler (but not interpreter) support for
i386, and Openblas dropped 32-bit support completely.  I think it's
going to become more and more difficult to offer a general-purpose
distribution on i386 well before we hit Y2038 problems.

Thanks,
Florian