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 -
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
