* 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
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 arch
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 *_t
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 th
* 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
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 th
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 contrib
On Fri, 19 Jul 2019 19:13:28 +0200, Florian Weimer wrote:
> * Adrian Bunk:
> > 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 stil
* 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
[ 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
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, si
11 matches
Mail list logo
