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 :|
