Re: Options for 64-bit time_t support on 32-bit architectures

2019-07-21 Thread Florian Weimer
* Simon McVittie: > On Fri, 19 Jul 2019 at 15:13:00 +0300, Adrian Bunk wrote: >> 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. > > Based

Re: Options for 64-bit time_t support on 32-bit architectures

2019-07-20 Thread Aurelien Jarno
On 2019-07-19 15:13, Adrian Bunk wrote: > 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 With the current way packages are built, i.e. natively on the same architecture, I don't see 32-bit

Re: Options for 64-bit time_t support on 32-bit architectures

2019-07-19 Thread Adam Borowski
On Fri, Jul 19, 2019 at 11:19:23PM +0300, Adrian Bunk wrote: > On Fri, Jul 19, 2019 at 07:13:28PM +0200, Florian Weimer wrote: > > Similar to the LFS support, with the > > additional property that binaries built in either mode should continue > > to work on kernels which predate support for the

Re: Options for 64-bit time_t support on 32-bit architectures

2019-07-19 Thread Aurelien Jarno
On 2019-07-19 23:19, Adrian Bunk wrote: > Support for the Intel Quark was dropped when the i386 baseline was > raised from 586 to 686 in stretch, so that's already irrelevant for > the Debian i386 port. Intel Quark has never been supported by Debian due to errata #71538, which requires to omit

Re: Options for 64-bit time_t support on 32-bit architectures

2019-07-19 Thread Florian Weimer
* Adrian Bunk: > On Fri, Jul 19, 2019 at 07:13:28PM +0200, Florian Weimer wrote: >> * Adrian Bunk: >>... >> For comparison, the original plan was to provide a macro, perhaps >> -D_TIME_BITS=32 and -D_TIME_BITS=64, to select at build time which ABI >> set is used (“dual ABI”). > > To me this would

Re: Options for 64-bit time_t support on 32-bit architectures

2019-07-19 Thread Adrian Bunk
On Fri, Jul 19, 2019 at 07:13:28PM +0200, Florian Weimer wrote: > * Adrian Bunk: >... > For comparison, the original plan was to provide a macro, perhaps > -D_TIME_BITS=32 and -D_TIME_BITS=64, to select at build time which ABI > set is used (“dual ABI”). To me this would sound like more trouble

Re: Options for 64-bit time_t support on 32-bit architectures

2019-07-19 Thread Simon McVittie
On Fri, 19 Jul 2019 at 15:13:00 +0300, Adrian Bunk wrote: > 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. Based on background from my

Re: Options for 64-bit time_t support on 32-bit architectures

2019-07-19 Thread Florian Weimer
* Adrian Bunk: > [ 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

Re: Options for 64-bit time_t support on 32-bit architectures

2019-07-19 Thread Adrian Bunk
[ 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

Options for 64-bit time_t support on 32-bit architectures

2019-07-18 Thread Florian Weimer
There is an effort under way to enhance glibc so that it can use the Y2038 support in the kernel. The result will be that more 32-bit architectures can use a 64-bit time_t. (Currently, it's x86-64 x32 only.) Originally, the plan was to support both ABIs in glibc for building new applications,