GNU bug report logs - #50985
Merging gnulib for Emacs 28.1?

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: stefan <at> marxist.se, 50985 <at> debbugs.gnu.org
Subject: bug#50985: Merging gnulib for Emacs 28.1?
Date: Mon, 04 Oct 2021 15:19:59 +0300

> From: Paul Eggert <eggert <at> cs.ucla.edu>
> Date: Sun, 3 Oct 2021 23:37:09 -0700
> Cc: 50985 <at> debbugs.gnu.org
> 
> OK, attached are proposed patches to emacs-28 to merge Gnulib into the 
> emacs-28 branch. This is intended to be what I posted to Bug#33847 in 
> July, except taking more-recent Emacs and Gnulib changes into account. 
> Although the 1st patch is large, it's almost all automatically-generated 
> by admin/merge-gnulib. I haven't tested the 2nd patch, as it's 
> Microsoft-specific and I am mostly just guessing about Microsoft.

Thanks.

> -Use --disable-largefile to omit support for files larger than 2GB on
> -systems which support that.
> +Use --disable-largefile to omit support for files larger than 2GB, and
> +--disable-year2038 to omit support for timestamps past the year 2038,
> +on systems which allow omitting such support.  This may help when
> +linking Emacs to a library with an ABI that requires a particular
> +width for off_t or for time_t.

At the time we discussed this, you said that --disable-year2038 has
effect only on 32-bit GNU/Linux x86 and ARM systems.  Is that still
so?  If so, I think we should mention that, as well as the relevant
glibc versions, otherwise this option's audience is not well defined
and users will not know whether it's for them or not.

The rest of the patches seem OK to me on first glance.  It is hard to
know whether they could cause problems, but I guess we will know soon
enough ;-)

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.