Re: Options for 64-bit time_t support on 32-bit architectures
[ only speaking for myself ]
On Thu, Jul 18, 2019 at 11:05:53PM +0200, Florian Weimer wrote:
>...
> The consequence is that in order to build 32-bit-time_t libraries
> (Gtk, for example), an old glibc needs to be kept around. In
> practice, it would probably mean that it is impossible to maintain a
> set of 32-bit-time_t libraries in a classic distribution build
> environment (with a unified buildroot and native builds).
>...
> Do you want to build 32-bit libraries (besides glibc) which are
> compatible with legacy applications, with a 32-bit time_t, in the
> future? Or is a world where time_t is pretty much always 64 bit
> something that would be acceptable?
So this is an ABI-incompatible change that would result in new Debian
architectures, similar to arm (OABI), armel (EABI softfp) and armhf
(EABI hardfp) being different Debian architectures for 32bit little
endian ARM?
There are two current release architectures where it is at least
imaginable that they will still be around closer to the year 2038:
i386 and armhf
For i386 the last newly released 32bit-only hardware were some early
Intel Atoms 10 years ago, and when the AMD Geode goes out of production
soon there might be no hardware in production left.
There are still surprisingly many people using Debian on 32bit-only
hardware, but in 20 years this will have changed.
Remaining usecases of i386 will be old binaries, some old Linux binaries
but especially old software (including many games) running in Wine.
Old Linux binaries will still need the old 32bit time_t.
Which options are viable from a Wine point of view?
For armhf new hardware might be available long enough to come close
to the year 2038, this might require a new architecture at some point.
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
Reply to: