Re: On time64 and Large File Support

["Richard W.M. Jones" <rjones@redhat.com>]

On Thu, Mar 02, 2023 at 02:28:28AM -0800, Paul Eggert wrote:
> On 2023-03-02 01:04, Daniel P. Berrangé wrote:
> >IMHO if distros really want to deal with this, they need to be able to
> >force _TIME_BITS=64 globally / unconditionally, and do a mass rebuild.
> 
> As things stand this is probably the best way to go. Although some
> pain is inevitable, this approach appears to be the least painful.

I think the question remains how to do this.  In Fedora we have a
concept of global C/C++ flags which most C/C++ applications obey:

$ rpm --eval '%{__global_cflags}'
-O2 -flto=auto -ffat-lto-objects -fexceptions -g -grecord-gcc-switches -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1  -m64  -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection

We could stick -D_TIME_BITS=64 in there and then do a mass rebuild.
We didn't historically do this for -D_FILE_OFFSET_BITS, instead
relying on every application to switch for itself.

As Dan says, back then everyone was using 32 bit machines routinely.
Now (in Fedora at least) this breakage in a core package on i686 has
barely been noticed.

Another way to look at this is that it's a bug in gnutls and we should
fix it only in this package (and in future other packages that expose
time_t directly through public ABIs).  Would probably require at least
some symbol version trickery.

Another factor here is that Fedora is in the process of dropping i686,
the last remaining 32 bit platform since we dropped armv7 a few
releases ago.  So maybe this is not a problem for Fedora.

Rich.

> Mainstream developers long ago migrated to 64-bit time_t, and fewer
> and fewer of them have the time to worry about the shrinking subset
> of the embedded system world where legacy 32-bit time_t is still OK
> (at least for the next several months). It's incumbent on system
> builders who still cater to legacy 32-bit time_t (for now) to figure
> out how to wrangle their systems into the 64-bit time_t world; they
> can't really expect Glibc, Gnulib, Autoconf, GnuTLS, etc. to make
> the job much easier than it already is.
> 
> 
> >So while there is a chance of inconsistent usage [with off_t], and thus
> >ABI incompatibility, in practice this is a non-issue since everything
> >of consequence has long ago opted in to _FILE_OFFSET_BITS=64.
> 
> Fifteen years from now we'll be saying the same thing about
> _TIME_BITS. There will be some pain in the meantime, just as there
> was with the _FILE_OFFSET_BITS transition, something I lived through
> and was not too happy about either.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
nbdkit - Flexible, fast NBD server with plugins
https://gitlab.com/nbdkit/nbdkit