[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: On time64 and Large File Support

From: Daniel P . Berrangé
Subject: Re: On time64 and Large File Support
Date: Fri, 3 Mar 2023 14:14:18 +0000
User-agent: Mutt/2.2.9 (2022-11-12)

On Fri, Mar 03, 2023 at 02:01:35PM +0000, Wookey wrote:
> On 2023-03-02 21:50 -0800, Paul Eggert wrote:
> > On 3/2/23 19:30, Wookey wrote:
> > > Gnulib automatically changing the ABI for packages that use it
> > > (and have LFS already enabled) is deeply unhelpful...
> > This change to Gnulib was reverted in December[1] and that propagated into
> > bleeding-edge GnuTLS last month[2]. So if I understand things correctly the
> > next GnuTLS release will go back to the old way of doing things,
> OK. gnulib doesn't seem to have releases as such (last release v0.1 9
> years ago), and is normally used embedded in the upstream source like
> autotools (right?). What is a good test for whether a package/upstream
> is affected by this 'gnulib might have turned 64-bit time' issue? Is
> there an embedded gnulib version one can check, or does one have to look
> at dates of the m4/year2038.m4 and m4/largefile.m4 files in the source?

Looks like you can probably detect it from the configure --help
output. Based on this commit:

> > [1]: 
> >

The original problematic impl has this:

- AC_ARG_ENABLE([year2038],
-   [  --disable-year2038      omit support for timestamps past the year 2038])

the new code which does not enable 2038 by default has

+  m4_provide_if([AC_SYS_YEAR2038],
+    [AS_HELP_STRING([--disable-year2038],
+      [do not support timestamps after 2038])],
+    [AS_HELP_STRING([--enable-year2038],
+      [support timestamps after 2038])]))])

So if

  configure --help | grep disable-year2038

says 'omit support for timestamps past the year 2038', the app is
suspect and might face ABI compat issues.

With regards,
|:      -o- :|
|:         -o-   :|
|:    -o- :|

reply via email to

[Prev in Thread] Current Thread [Next in Thread]