Re: On time64 and Large File Support

[Wookey <wookey@wookware.org>]

[-- Attachment #1: Type: text/plain, Size: 3070 bytes --]

On 2023-03-02 13:24 +0000, Daniel P. Berrangé wrote:
> 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.

There are lots. I'm nearly 6000 packages into a 10,325 *-dev package
analysis in debian and have so far found 218 packages where enabling
_TIME_BITS=64 changes the ABI. (and 39 where enabling LFS changes the
ABI - implying that they are not being built with it now). 1068 didn't
change, (and 3713 don't actually contain a lib or headers - like 2000
golang* packages, and 895 need further analysis - many because the
libs and headers are not in the same package). So there could be
around 500 packages affected. (It was about 130 in Ubuntu main)

Gnulib automatically changing the ABI for packages that use it is
deeply unhelpful and is going to cause significant breakage and
hassle. I'd better start checking how many libraries in debian have
had their ABI incompatibly-changed already. Just because most users
are on 64-bit systems is no excuse for randomly breaking the 32-bit
ones.

We do need to make this transition in 32-bit world, but it also needs
to be done in an orderly fashion like any other ABI-breaking
transition - with SONAME changes and ordered uploads (or decide it's
too big, not do that, and start a new triplet/architecture). Neither
of these involves randomly changing the ABI on some libraries just
because they updated their gnulib.

I gave a FOSDEM talk on the state of play about a month ago on this
general issue in case anyone
cares:https://fosdem.org/2023/schedule/event/fixing_2038/

> 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.

Right.

> 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.

Which is essentially x32, that has existed for some years (but has had
little adoption).  Debian builds it as an unoffical (i.e 'best
effort') port.

Wookey
-- 
Principal hats:  Debian, Wookware, ARM
http://wookware.org/

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]