From: "Michał Górny" <mgorny@gentoo.org>
To: gentoo-project@lists.gentoo.org
Cc: council@gentoo.org
Subject: Re: [gentoo-project] Council meeting tomorrow 13.10.
Date: Sun, 13 Oct 2024 13:42:58 +0200 [thread overview]
Message-ID: <45bc2140cc12cda89ed06bbe9f960ea8d890368f.camel@gentoo.org> (raw)
In-Reply-To: <uttdgw8tt@gentoo.org>
[-- Attachment #1: Type: text/plain, Size: 1988 bytes --]
On Sun, 2024-10-13 at 13:17 +0200, Ulrich Mueller wrote:
> > > > > > On Sun, 13 Oct 2024, Michał Górny wrote:
>
> > While I don't think we need to take any formal decision about it, I'd
> > like to discuss / reiterate our plans wrt time64 transition.
> > Particularly, I'd like to merge [1] soon, and then request a backport,
> > so I'd prefer a confirmation that we're likely to proceed with these
> > triplets.
>
> > [1] https://github.com/llvm/llvm-project/pull/111302
>
> AFAICS the relevant document would be this?
> https://wiki.gentoo.org/wiki/Project:Toolchain/time64_migration
>
> Please, could somebody from the Toolchain project summarise which of the
> possible solutions outlined there is planned?
The ones I was experimenting most recently were:
- append "t64" to CHOST
- make gcc default to time64 (via USE flag?)
- make clang use time64 when CHOST ends with "t64"
On top of that, time64-prep [1] to prepare a safer transition path.
[1] https://github.com/projg2/time64-prep
> Also, the wiki page mentions Large File Support. Is that an independent
> issue, or does time64 imply LFS (or vice versa)?
glibc requires LFS to be enabled for time64. So we're pretty much
moving from baseline of no-LFS + time32 (with some packages enabling one
or both) to LFS + time64. We're calling it "t64" for short because LFS
is implied.
> I've seen some discussion with other distros on the distributions
> mailing list. What is the status there? No consensus, everybody doing
> their own thing?
Yes, pretty much, something between "Debian did it without CHOST change,
so it must be fine", and "I like my CHOST, let's change CHOST for time32
systems instead." However, I didn't see a strict opposition to us doing
it either. GNU toolchain people don't care (it ignores extra suffixes),
and the only person from clang I was able to get to reply didn't mind
and approved the patch.
--
Best regards,
Michał Górny
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 512 bytes --]
prev parent reply other threads:[~2024-10-13 11:43 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-10-12 16:31 [gentoo-project] Council meeting tomorrow 13.10 Andreas K. Huettel
2024-10-13 10:19 ` Michał Górny
2024-10-13 11:17 ` Ulrich Mueller
2024-10-13 11:42 ` Michał Górny [this message]
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=45bc2140cc12cda89ed06bbe9f960ea8d890368f.camel@gentoo.org \
--to=mgorny@gentoo.org \
--cc=council@gentoo.org \
--cc=gentoo-project@lists.gentoo.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