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:
signature.asc
Description: PGP signature
