Paul Eggert wrote:
> I installed the attached patch to address the problem you mentioned.
I'm pulling it into Gnulib:
2023-05-14 Paul Eggert
year2038-recommended: Improve failure diagnostic.
* m4/largefile.m4 (AC_SYS_YEAR2038_RECOMMENDED): Sync from Autoconf.
diff --git a/m4
Paul Eggert wrote:
> I installed the attached patch to address the problem you mentioned.
Thank you.
Good wording is important here; the new wording is better than what I had
proposed.
Bruno
On 2023-05-12 05:32, Bruno Haible wrote:
there are two AC_MSG_FAILURE invocations. Removing this
line from the invocation in AC_SYS_YEAR2038_RECOMMENDED does not remove it
from the invocation in AC_SYS_YEAR2038.
Oh, thanks for explaining that. I installed the attached patch to
address the prob
Bruno Haible wrote:
[...]
* In the other cases
- 32-bit OS, or
Perhaps this has already been addressed, but what prevents a 32-bit OS
from nonetheless having a 64-bit time_t?
Do the tests accommodate the possibility of time_t being long long?
They should: there is no reason to ex
Jacob Bachmeyer wrote:
> Perhaps this has already been addressed, but what prevents a 32-bit OS
> from nonetheless having a 64-bit time_t?
Nothing. That's the case in particular on
- Linux on arc, loong32, ork1, riscv32 and x86_64-x32,
- NetBSD 6.0 (2012) and later on x86 and sparc,
- OpenBSD 5.5
Paul Eggert wrote:
> > 3) The hint
> >
> > Did you mean to build a 64-bit binary? (E.g.,
> > 'CC="gcc -m64"'.)
> >
> > should not occur on a 32-bit OS. It should only occur on bi-arch systems
> > (64-bit OS, 32-bit $CC).
>
> If we could come up with a reliable way to distinguish between th
On 5/6/23 06:09, Bruno Haible wrote:
3) The hint
Did you mean to build a 64-bit binary? (E.g.,
'CC="gcc -m64"'.)
should not occur on a 32-bit OS. It should only occur on bi-arch systems
(64-bit OS, 32-bit $CC).
If we could come up with a reliable way to distinguish between the two,
Hi Paul,
> > I see two issues:
> >
> > 1) For AC_SYS_YEAR2038 and AC_SYS_YEAR2038_RECOMMENDED, when run on a 32-bit
> > platform (x86) with glibc < 2.34, there is no
> >checking for <$CC> option for timestamps after 2038...
> > line in the output. It _looks_like_ the macro was not invoked or
On 2023-04-20 09:02, Bruno Haible wrote:
I see two issues:
1) For AC_SYS_YEAR2038 and AC_SYS_YEAR2038_RECOMMENDED, when run on a 32-bit
platform (x86) with glibc < 2.34, there is no
checking for <$CC> option for timestamps after 2038...
line in the output. It _looks_like_ the macro was not in
On Wed, Apr 19, 2023 at 02:14:05PM -0700, Paul Eggert wrote:
> +++ b/doc/autoconf.texi
> @@ -8808,18 +8808,20 @@ if possible. These types may include
> @code{blkcnt_t}, @code{dev_t},
>
> Also, arrange for a @command{configure} option @code{--enable-year2038}
> to request widening the type @co
On 2023-04-16 08:35, Bruno Haible wrote:
There's still the rename of AC_SYS_YEAR2038_REQUIRED to AC_SYS_YEAR2038_OPT_OUT
to do, that you proposed in [1] and Zack agreed [2].
Attached are proposed patches to do something along those lines, the
first for Autoconf and the second to propagate this
11 matches
Mail list logo
