* Florian Weimer:
> For Fedora, that would affect the i686 architecture only.
It was pointed out off-list that I forgot armhfp. Sorry!
The external pressure to keep armhfp going indefinitely and switch to
a 64-bit time_t is probably larger on armhfp than on i686. The reason
is that new armhfp
* Michael Cronenworth:
> On 7/18/19 4:05 PM, Florian Weimer wrote:
>> Old binaries with a 32-bit time_t will continue to run, but new
>> binaries built against a current glibc will always use a 64-bit time_t
>> under this approach.
> How would this affect Wine's handling of 32-bit PE binaries?
On 7/18/19 4:05 PM, Florian Weimer wrote:
Old binaries with a 32-bit time_t will continue to run, but new
binaries built against a current glibc will always use a 64-bit time_t
under this approach.
How would this affect Wine's handling of 32-bit PE binaries? I'm assuming they will also
break
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,
