[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]:
> > https://git.savannah.gnu.org/cgit/gnulib.git/commit/?id=7c7c8a519f3892f6f5b30a1c6b22796ab314a45c
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
+[AC_ARG_ENABLE([year2038],
+ 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,
Daniel
--
|: 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 :|
- Re: On time64 and Large File Support, Eric Blake, 2023/03/01
- Re: On time64 and Large File Support, Demi Marie Obenour, 2023/03/01
- Re: On time64 and Large File Support, Daniel P . Berrangé, 2023/03/02
- Re: On time64 and Large File Support, Paul Eggert, 2023/03/02
- Re: On time64 and Large File Support, Richard W.M. Jones, 2023/03/02
- Re: On time64 and Large File Support, Bruno Haible, 2023/03/02
- Re: On time64 and Large File Support, Daniel P . Berrangé, 2023/03/02
- Re: On time64 and Large File Support, Wookey, 2023/03/02
- Re: On time64 and Large File Support, Paul Eggert, 2023/03/03
- Re: On time64 and Large File Support, Wookey, 2023/03/03
- Re: On time64 and Large File Support,
Daniel P . Berrangé <=
- Re: On time64 and Large File Support, Arsen Arsenović, 2023/03/04
- Re: On time64 and Large File Support, Florian Weimer, 2023/03/03
- Re: On time64 and Large File Support, Richard W.M. Jones, 2023/03/03
- Re: On time64 and Large File Support, Andreas Schwab, 2023/03/02
- Re: On time64 and Large File Support, Paul Eggert, 2023/03/03
- Re: On time64 and Large File Support, Andreas Schwab, 2023/03/06
- Re: On time64 and Large File Support, Florian Weimer, 2023/03/06
Re: On time64 and Large File Support, Richard W.M. Jones, 2023/03/02