On 6/6/22 13:29, Petr Pisar wrote:
V Mon, Jun 06, 2022 at 12:07:18PM +0200, Miroslav Lichvar napsal(a):
> On Thu, Jun 02, 2022 at 05:46:05PM +0200, Petr Pisar wrote:
>> $ gcc -m32 -D_TIME_BITS=64 -D_FILE_OFFSET_BITS=64 main.c
>> $ ./a.out
>> sizeof(time_t)=8
>>
>> I recommend you to file a bug against tar in Fedora's Bugzilla. However,
this
>> proposed solution would require rebuilding in the same way all libraries which
>> tar uses and which pass time_t and similar types in their interface. That
>> would probably break other packages.
>
> Now that the kernel and glibc have this feature, would it make sense
> to change the global CFLAGS to build everything with 64-bit time_t on
> all currently supported 32-bit archs? If not now, how close to the
> 32-bit overflow in 2038?
>
That would be ideal, but I worry that Fedora will rather drop i686 archicture
than change ABI of all packages.
Most of the uses cases for i686 is a multilib for proprietary software.
Changing ABI would break it. How much of that software will be relevant in 15
years?
The way glibc compatibility works, existing binaries will continue to
get the ABIs they were built with once upon a time and continue to work
like nothing ever happened. Except of course that time will wrap around
eventually.
Or at least that's how the theory goes, IIRC the time_t transition has
its own peculiarities that other similar transitions haven't had.
We dropped 32-bit ARM because we were unable to build the software (in
a reasonable time). As software becomes hungrier (and less tested on 32 bits), we
start observing the same problem in i686.
Yup, but i686 can be easily built on x86_64 which alleviates things
quite a bit.
- Panu -