Re: On time64 and Large File Support

> On 12 Nov 2022, at 04:56, Wookey wrote: > > On 2022-11-12 04:28 +, Sam James wrote: >> >> >>> On 12 Nov 2022, at 04:20, Wookey wrote: >>> >>> Distros need to co-ordinate on this. If there are going to be new >>> triplets for the 'LFS and 64_bit timet' ABI(s) then we should agree on

Re: On time64 and Large File Support

On 2022-11-12 04:28 +, Sam James wrote: > > > > On 12 Nov 2022, at 04:20, Wookey wrote: > > > > Distros need to co-ordinate on this. If there are going to be new > > triplets for the 'LFS and 64_bit timet' ABI(s) then we should agree on > > them and use them. If distros are happy to

Re: On time64 and Large File Support

> On 12 Nov 2022, at 04:20, Wookey wrote: > > On 2022-11-11 10:19 +0100, Florian Weimer wrote: > > Hi. I've started looking into the 64-bit time_t transition for 32-bit armhf > in Debian. We are currently doing a preliminary bootstrap to see what > breaks. We strongly suspect that only a

Re: On time64 and Large File Support

On 2022-11-11 10:19 +0100, Florian Weimer wrote: Hi. I've started looking into the 64-bit time_t transition for 32-bit armhf in Debian. We are currently doing a preliminary bootstrap to see what breaks. We strongly suspect that only a wholesale rebuild for the new ABI (i.e a new Debian

Re: How can Autoconf help with the transition to stricter compilation defaults?

> On 12 Nov 2022, at 00:53, Paul Eggert wrote: > > On 2022-11-11 15:25, Sam James wrote: >> That's not a judgement on whether the changes will ultimately remain in >> autoconf, I'm just >> hesitant to allow a discussion I've kicked off to derail something that we >> were planning >> on doing

Re: On time64 and Large File Support

> On 12 Nov 2022, at 02:20, Zack Weinberg via Libc-alpha > wrote: > > Sam James writes: >>> On 11 Nov 2022, at 09:19, Florian Weimer wrote: >>> We need to support legacy binaries on i386. Few libraries are >>> explicitly dual-ABI. Whether it's safe to switch libraries above glibc >>> to

Re: How can Autoconf help with the transition to stricter compilation defaults?

Bob Friesenhahn writes: > On Thu, 10 Nov 2022, Zack Weinberg wrote: >> The biggest remaining (potential) problem, that I’m aware of, is that >> AC_CHECK_FUNC unconditionally declares the function we’re probing for >> as ‘char NAME (void)’ > > This does seem like the biggest problem since it would

Re: How can Autoconf help with the transition to stricter compilation defaults?

On Fri, 11 Nov 2022, Zack Weinberg via Gcc wrote: > These are also a trip hazard for novices, and the only way to turn them > off is with -std=cXX, which also turns another trip hazard (trigraphs) > *on*… so yeah, anything you can do to help speed up their removal, I > think it’d be worthwhile.

Re: How can Autoconf help with the transition to stricter compilation defaults?

> On 12 Nov 2022, at 03:40, Zack Weinberg wrote: > > Florian Weimer writes: >> based on a limited attempt to get this fixed about three years >> ago, I expect that many of the problematic packages have not had their >> configure scripts regenerated using autoconf for a decade or more. This

Re: How can Autoconf help with the transition to stricter compilation defaults?

Florian Weimer writes: > based on a limited attempt to get this fixed about three years > ago, I expect that many of the problematic packages have not had their > configure scripts regenerated using autoconf for a decade or more. This > means that as an autoconf maintainer, you unfortunately

Re: How can Autoconf help with the transition to stricter compilation defaults?

Rich Felker writes: > On Thu, Nov 10, 2022 at 12:16:20PM -0500, Zack Weinberg wrote: >> The biggest remaining (potential) problem, that I’m aware of, is that >> AC_CHECK_FUNC unconditionally declares the function we’re probing for >> as ‘char NAME (void)’, and asks the compiler to call it with no

Re: How can Autoconf help with the transition to stricter compilation defaults?

Nick Bowler writes: > My gut feeling is that Autoconf should just determine the necessary > options to get compatible behaviour out of these modern compilers, at > least for the purpose of running configure tests. For example, Autoconf > should probably build the AC_CHECK_FUNC programs using

Re: How can Autoconf help with the transition to stricter compilation defaults?

On 11/10/22 15:19, Paul Eggert wrote: > On 2022-11-10 09:16, Zack Weinberg wrote: >> Changes to handle C23 built-in ‘bool’ better are under development but >> the design has not yet been finalized. > > [I'm cc'ing this to bug-gnulib too.] > > To my mind this is the biggest outstanding issue in

Re: On time64 and Large File Support

Sam James writes: >> On 11 Nov 2022, at 09:19, Florian Weimer wrote: >> We need to support legacy binaries on i386. Few libraries are >> explicitly dual-ABI. Whether it's safe to switch libraries above glibc >> to LFS or time64 needs to be evaluated on a per-library basis. For most >>

Re: How can Autoconf help with the transition to stricter compilation defaults?

On 2022-11-11 15:25, Sam James wrote: That's not a judgement on whether the changes will ultimately remain in autoconf, I'm just hesitant to allow a discussion I've kicked off to derail something that we were planning on doing anyway. What do you think? I'm hesitant to do that partly

Re: On time64 and Large File Support

On Fri, 11 Nov 2022, Paul Eggert wrote: > One possible way forward would be for glibc to change its defaults for > _FILE_OFFSET_BITS and _TIME_BITS to be 64, in the next major release. This See my notes at on what would be

Re: On time64 and Large File Support

On 2022-11-11 03:38, Florian Weimer wrote: But that said, these binaries are broken anyway in 2038? No, I expect users to run them in time-shifted VMs or containers. That's reasonable for systems where accurate timestamps are not important and where time_t width mismatches would just get in

Re: On time64 and Large File Support

On Fri, 11 Nov 2022 11:01:50 PST (-0800), libc-al...@sourceware.org wrote: >> We need to support legacy binaries on i386. Few libraries are >> explicitly dual-ABI. Whether it's safe to switch libraries above >> glibc to LFS or time64 needs to be evaluated on a per-library >> basis. For most

Re: On time64 and Large File Support

On 2022-11-11 03:22, Florian Weimer wrote: Fortunately, any issues should be quite visibile in the distribution DWARF data. If we put the time32 switch in place, we should be able to tell whether it's effective enough in practice. OK, thanks; if problems turn up in that area please let the

Re: On time64 and Large File Support

> >> We need to support legacy binaries on i386. Few libraries are > >> explicitly dual-ABI. Whether it's safe to switch libraries above > >> glibc to LFS or time64 needs to be evaluated on a per-library > >> basis. For most distributions, no one is going to do that work, > >> and we have to

Re: How can Autoconf help with the transition to stricter compilation defaults?

On Thu, Nov 10, 2022 at 4:05 PM Paul Eggert wrote: > > On 2022-11-10 10:19, Aaron Ballman wrote: > > In terms of the Clang side of things, I don't think we've formed any > > sort of official stance on how to handle that yet. It's UB (you can > > declare the C standard library interface without UB

Re: On time64 and Large File Support

> > > > Proposal: glibc gains two new build-time configure options: > > * --enable-hard-time64 > > * --enable-hard-lfs > > We should define new target triplets for this if it's really required. > That doesn't really help anyone *but* Debian ... > We need to support legacy binaries on i386.

Re: On time64 and Large File Support

* Sam James: >> On 11 Nov 2022, at 09:19, Florian Weimer wrote: >> >> * Sam James: >> >>> In Gentoo, we've been planning out what we should do for time64 on >>> glibc [0] and concluded that we need some support in glibc for a newer >>> option. I'll outline why below. >>> >>> Proposal: glibc

Re: On time64 and Large File Support

* Andreas K. Huettel: >> > >> > Proposal: glibc gains two new build-time configure options: >> > * --enable-hard-time64 >> > * --enable-hard-lfs >> >> We should define new target triplets for this if it's really required. >> > > That doesn't really help anyone *but* Debian ... > >> We need to

Re: On time64 and Large File Support

* Paul Eggert: > On 2022-11-11 01:19, Florian Weimer wrote: > >> AC_SYS_LARGEFILE defaulting to AC_SYS_YEAR2038 is extremely destructive >> for Fedora unfortunately. >> I thought the gnulib change has been reverted? > > I'm not sure where you got that impression. Bleeding-edge (unreleased) >

Re: On time64 and Large File Support

On Fri, 2022-11-11 at 08:38 +, Sam James wrote: > In Gentoo, we've been planning out what we should do for time64 on glibc [0] > and concluded that we need some support in glibc for a newer option. I'll > outline > why below. > > Proposal: glibc gains two new build-time configure options: >

Re: On time64 and Large File Support

On 2022-11-11 01:19, Florian Weimer wrote: AC_SYS_LARGEFILE defaulting to AC_SYS_YEAR2038 is extremely destructive for Fedora unfortunately. I thought the gnulib change has been reverted? I'm not sure where you got that impression. Bleeding-edge (unreleased) Autoconf AC_SYS_LARGEFILE, along

Re: On time64 and Large File Support

> On 11 Nov 2022, at 09:19, Florian Weimer wrote: > > * Sam James: > >> In Gentoo, we've been planning out what we should do for time64 on >> glibc [0] and concluded that we need some support in glibc for a newer >> option. I'll outline why below. >> >> Proposal: glibc gains two new

Re: On time64 and Large File Support

> On 11 Nov 2022, at 09:16, Paul Eggert wrote: > > On 2022-11-11 00:38, Sam James wrote: >> All that to say, I don't propose making these options unconditional, >> because I think the boat has sailed as of glibc-2.34 [4], and I think >> it's fair that autoconf keep the behaviour as described

Re: On time64 and Large File Support

* Sam James: > In Gentoo, we've been planning out what we should do for time64 on > glibc [0] and concluded that we need some support in glibc for a newer > option. I'll outline why below. > > Proposal: glibc gains two new build-time configure options: > * --enable-hard-time64 > *

Re: On time64 and Large File Support

On 2022-11-11 00:38, Sam James wrote: All that to say, I don't propose making these options unconditional, because I think the boat has sailed as of glibc-2.34 [4], and I think it's fair that autoconf keep the behaviour as described in git master right now given the situation with glibc, but I

Re: How can Autoconf help with the transition to stricter compilation defaults?

> On 10 Nov 2022, at 17:16, Zack Weinberg wrote: > > I’m the closest thing Autoconf has to a lead maintainer at present. > > It’s come to my attention (via https://lwn.net/Articles/913505/ and > https://fedoraproject.org/wiki/Changes/PortingToModernC) that GCC and > Clang both plan to disable

Re: How can Autoconf help with the transition to stricter compilation defaults?

> On 11 Nov 2022, at 03:33, Zack Weinberg wrote: > > On Thu, Nov 10, 2022, at 10:08 PM, Sam James wrote: >>> On 10 Nov 2022, at 21:10, Michael Orlitzky wrote: >>> While everyone else is discussing big ideas, it would be helpful for me >>> personally if autoconf just made a release with the

On time64 and Large File Support

Hi all, In Gentoo, we've been planning out what we should do for time64 on glibc [0] and concluded that we need some support in glibc for a newer option. I'll outline why below. Proposal: glibc gains two new build-time configure options: * --enable-hard-time64 * --enable-hard-lfs These would