Re: On time64 and Large File Support

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

 



On Thu, Mar 02, 2023 at 01:17:33PM +0100, Bruno Haible wrote:
> Richard W.M. Jones wrote:
> > Another way to look at this is that it's a bug in gnutls and we should
> > fix it only in this package
> 
> It's by far not just this one package. An 'fgrep -rl time_t /usr/include'
> search shows a number of libraries that use time_t in their API:
>   alsa, boost, libstdc++, glib-2.0, gtk+-3.0, libpng, nettle, openssl,
>   readline, libuuid, wxwidgets, X11, libxcb
> - and that's just the few that I happen to have installed.
> 
> If a distro takes a package-by-package approach:
>   - Some of these packages use Gnulib, and are thus causing trouble now or
>     will soon.
>   - The other packages (and there are a number of them!) will either
>     require a manual switch to _TIME_BITS=64 or blow up in 2038.

To be clear, Fedora does not want to take a package-by-package
approach at all. It is getting imposed when we pick up new software
releases that happen to enable _TIME_BITS=64, either intentionally
or unwittingly.

> I agree with Daniel and Paul that a global switch to _TIME_BITS=64 + mass
> rebuild is
>   - more efficient than a package-by-package approach,
>   - also less likely to leave out some packages by mistake.

On the Fedora side, the i686 support is very much of declining
relevance. Fedora approved the removal of "leaf" node packages
aka applications[1]. The remaining focus is primarily around
libraries so that 32-bit libs can be used on a 64-bit OS install
to support running 32-bit application binaries obtained from
external sources (primarily wine + steam related).

Those 32-bit binaries being targeted are going to be exclusively
using 32-bit time_t. IOW, doing a mass rebuild of the distro with
_TIME_BITS=64 will break compatibility with the very apps that
motivate the continued existance of i686 as a build target.

Thus from the Fedora POV the only viables paths I see are either
keeping with 32-bit time_t, or dropping i686 entirely. I would
expect Fedora to fully drop i686 before 2038 arrives anyway.

Other distros may have different priorities and find a mass
rebuild to enable 64-bit time_t interesting for their needs.
Most especially if their world is self-contained and thus
does not need to worry about compatibility with externally
distributed 32-bit binaries using 32-bit time_t.

Essentially i686 with 64-bit time_t needs to be considered
an entirely new build target. Either distros want to support
to this new target as a whole, or they want to stick with
the old target.

With regards,
Daniel

[1] https://fedoraproject.org/wiki/Changes/EncourageI686LeafRemoval
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|





[Index of Archives]     [GCC Help]     [Kernel Discussion]     [RPM Discussion]     [Red Hat Development]     [Yosemite News]     [Linux USB]     [Samba]

  Powered by Linux