Re: Archive value is out of time_t range

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



V Mon, Jun 06, 2022 at 02:40:50PM +0300, Panu Matilainen napsal(a):
> 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.
> 
I believe that glibc payed a special attention to provide both ABIs. But that
does not apply to other libraries. Maybe it's not so important problem.
Proprietary software tends to bundle the libraries, externally relying only on
kernel and glibc.

> 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.
> 
Wasn't that also said about ARMv7 on AArch64?

-- Petr

Attachment: signature.asc
Description: PGP signature

_______________________________________________
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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux