Re: On time64 and Large File Support

--OxDG9cJJSSQMUzGF
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On 2023-03-02 13:24 +0000, Daniel P. Berrang=E9 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
> >=20
> > It's by far not just this one package. An 'fgrep -rl time_t /usr/includ=
e'
> > 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.
> >=20
> > 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=3D64 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=3D64 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=3D64 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
--=20
Principal hats:  Debian, Wookware, ARM
http://wookware.org/

--OxDG9cJJSSQMUzGF
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEER4nvI8Pe/wVWh5yq+4YyUahvnkcFAmQBad8ACgkQ+4YyUahv
nkdXZg//VwHkH6c4+uaeB/+me1s9y6xo40sqGXW4Dz6aWei0eEcqGWtXHEwqU4f+
gERgW/zH2wRuPW/mPTP3Q3PLg1lljiTx3fAADdffX4sq4C7XkrCFu+R2vUPe58IH
4sSKIyyOrE7ZMhcNuDjGDZeZ+qEx88lcD2kMFC/CcnSNSQsfg6HsR/eYtQvVc3T/
1DXovFT5+IoW8PhoAosrqemGUmfvk85el4Nk1crMTQAZqiSb6aTWCk7IOBXKYnju
6j2XfpktkMiFcxJF2yhWKpg3mzt8TjCRzXAye1qsgU3YubgU92kYpVMI8eil4cMk
cUxjSeeTh0JxwSUYmJPudR8+pjOACByVXUhM2b09yE141S6HK7XtpFhmWwJEBep1
LkEX7K3khvLSkLG+B4+lrcJoErz+30cnELw/TNCu2tX8ektWj7U71824yoWmBayx
vxjiqc5fHJPTz7aJjPqu+7iDJgF5HMYBfapdmPYXe4++WOVyg/C6zCAvOQVCZZgX
v/4IZD2N+mGPkv9le185+xWlNkWq4mSWQybQsK+KghisM1n1oCX/OlNoQEKctwCc
mScyAuvfy/JXq1exABVRtq2qFNOtc7mK9mKIZHmKTggK+D5+ox43ZV1VkvDrciQw
uaRQbVl8giMkym0PG/obRWiDacE25rGDu/3cg4tTPJkSkQQwZ8M=
=SBT0
-----END PGP SIGNATURE-----

--OxDG9cJJSSQMUzGF--