public inbox for libc-alpha@sourceware.org
 help / color / mirror / Atom feed
From: "Daniel P. Berrangé" <berrange@redhat.com>
To: Bruno Haible <bruno@clisp.org>
Cc: "Paul Eggert" <eggert@cs.ucla.edu>,
	"Richard W.M. Jones" <rjones@redhat.com>,
	"Demi Marie Obenour" <demiobenour@gmail.com>,
	"Eric Blake" <eblake@redhat.com>, "Sam James" <sam@gentoo.org>,
	"Carlos O'Donell via Libc-alpha" <libc-alpha@sourceware.org>,
	autoconf@gnu.org, c-std-porting@lists.linux.dev,
	"Zack Weinberg" <zack@owlfolio.org>,
	"David Seifert" <soap@gentoo.org>,
	"Gentoo Toolchain" <toolchain@gentoo.org>,
	"Arsen Arsenović" <arsen@aarsen.me>,
	dueno@redhat.com
Subject: Re: On time64 and Large File Support
Date: Thu, 2 Mar 2023 13:24:48 +0000	[thread overview]
Message-ID: <ZACjoKgDMiaJce9Z@redhat.com> (raw)
In-Reply-To: <4158136.ciBtUerH68@nimes>

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


  reply	other threads:[~2023-03-02 13:24 UTC|newest]

Thread overview: 56+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-11-11  8:38 Sam James
2022-11-11  9:16 ` Paul Eggert
2022-11-11  9:19   ` Sam James
2022-11-11 23:48   ` Joseph Myers
2022-11-11  9:19 ` Florian Weimer
2022-11-11  9:27   ` Sam James
2022-11-11 11:38     ` Florian Weimer
2022-11-11 20:12       ` Paul Eggert
2022-11-12  2:20     ` Zack Weinberg
2022-11-12  3:57       ` Sam James
2022-11-12 14:16         ` Zack Weinberg
2022-11-12 17:41           ` Paul Eggert
2022-11-12 18:50             ` Bruno Haible
2022-11-12 19:15               ` Paul Eggert
2022-11-12 20:23                 ` Wookey
2022-11-12 20:54                   ` Russ Allbery
2022-11-12 21:31                   ` Paul Eggert
2022-11-15  5:09                     ` Sam James
2022-11-12 18:19       ` Paul Eggert
2022-11-11  9:40   ` Andreas K. Huettel
2022-11-11 11:30     ` Florian Weimer
2022-11-11 19:01       ` Andreas K. Huettel
2022-11-11 19:28         ` Palmer Dabbelt
2022-11-11  9:46   ` Paul Eggert
2022-11-11 11:22     ` Florian Weimer
2022-11-11 19:56       ` Paul Eggert
2022-11-12  4:20   ` Wookey
2022-11-12  4:28     ` Sam James
2022-11-12  4:56       ` Wookey
2022-11-12  4:59         ` Sam James
2022-11-12 18:33     ` Paul Eggert
2022-11-14  8:39   ` Adam Sampson
2022-11-14 11:47     ` Florian Weimer
2022-11-14 20:26     ` Arsen Arsenović
2022-11-14 20:52       ` Florian Weimer
2022-11-15  7:39         ` Arsen Arsenović
2022-11-11 10:25 ` Richard Purdie
2023-03-01 22:38 ` Eric Blake
2023-03-02  0:29   ` Demi Marie Obenour
2023-03-02  9:04     ` Daniel P. Berrangé
2023-03-02 10:28       ` Paul Eggert
2023-03-02 10:38         ` Andreas Schwab
2023-03-03  5:46           ` Paul Eggert
2023-03-06  8:58             ` Andreas Schwab
2023-03-06 10:19               ` Florian Weimer
2023-03-02 11:02         ` Richard W.M. Jones
2023-03-02 12:17           ` Bruno Haible
2023-03-02 13:24             ` Daniel P. Berrangé [this message]
2023-03-03  3:30               ` Wookey
2023-03-03  5:50                 ` Paul Eggert
2023-03-03 14:01                   ` Wookey
2023-03-03 14:14                     ` Daniel P. Berrangé
2023-03-03 23:21             ` Arsen Arsenović
2023-03-03 11:49           ` Florian Weimer
2023-03-03 12:39             ` Richard W.M. Jones
2023-03-02  8:30   ` Richard W.M. Jones

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ZACjoKgDMiaJce9Z@redhat.com \
    --to=berrange@redhat.com \
    --cc=arsen@aarsen.me \
    --cc=autoconf@gnu.org \
    --cc=bruno@clisp.org \
    --cc=c-std-porting@lists.linux.dev \
    --cc=demiobenour@gmail.com \
    --cc=dueno@redhat.com \
    --cc=eblake@redhat.com \
    --cc=eggert@cs.ucla.edu \
    --cc=libc-alpha@sourceware.org \
    --cc=rjones@redhat.com \
    --cc=sam@gentoo.org \
    --cc=soap@gentoo.org \
    --cc=toolchain@gentoo.org \
    --cc=zack@owlfolio.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).