Re: gnutls time_t breakage on i686 (was: Re: qemu on i686)

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

 



On Thu, Mar 02, 2023 at 02:35:11PM +0100, Miroslav Lichvar wrote:
> On Thu, Mar 02, 2023 at 11:57:42AM +0000, Daniel P. Berrangé wrote:
> > If any other Fedora maintainer looks after packages that use GNULIB,
> > then it is quite likely that they also need to add --disable-year2038
> > to their specfiles to avoid i686 brokenness when talking to any
> > non-glibc libraries that use time_t, or exposing a library using time_t
> 
> There are about 150 packages that provide "bundled(gnulib)". About 50
> have "lib" in their name. Just wondering, wouldn't it be less work to
> enable 64-bit time_t in the rpm CFLAGS, rebuild everything, and deal
> with a potentially smaller number of broken packages with the benefit
> of fixing Y2038?

So a few facts first:

(1) Gnulib, in some common circumstances, sets -D_TIME_BITS=64

(2) Programs might also choose to set -D_TIME_BITS=64, even if they
don't use Gnulib.

(3) This flag only affects 32 bit platforms like i686 and armv7,
changing time_t from 32 to 64 bit.

(4) Also this only matters if time_t leaks into header files, because
it could cause the library's ABI to change.  If time_t is used
entirely internal to the program/library, it shouldn't be a problem.

(5) A problem arises when the caller and callee disagree on the size
of time_t.

Now, as Dan points out in the linked thread on libc-alpha, the reason
we have i686 in Fedora at all is to support third party programs like
Wine and Steam.  Those may still be using 32-bit time_t for a while.
That's an argument for sticking with the current situation.

This might change in future -- eg. if these external programs are
being compiled on, say, Debian, and Debian were to switch to using
-D_TIME_BITS=64 everywhere, and we found more programs expecting it,
then we'd have to switch.  You can see why this is going to be
problematic for the period where there are mixed old & new binaries.

Also libraries that do expose raw time_t in header files are actually
broken.  Really they should expose an explicit 64 bit type
(eg. int64_t) and converting to time_t internally.  But probably that
ship has sailed.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
libguestfs lets you edit virtual machines.  Supports shell scripting,
bindings from many languages.  http://libguestfs.org
_______________________________________________
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, report it: https://pagure.io/fedora-infrastructure/new_issue




[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