[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#50985: Merging gnulib for Emacs 28.1?
From: |
Andy Moreton |
Subject: |
bug#50985: Merging gnulib for Emacs 28.1? |
Date: |
Tue, 05 Oct 2021 00:18:11 +0100 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (windows-nt) |
On Mon 04 Oct 2021, Eli Zaretskii wrote:
>> From: Paul Eggert <eggert@cs.ucla.edu>
>> Date: Sun, 3 Oct 2021 23:37:09 -0700
>> Cc: 50985@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 ;-)
After these gnulib updates were installed I tried bootstrapping emacs-28
from a clean git tree on Windows (mingw64 64bit). After autogen and
configure, make failed with several errors of the form:
In file included from C:/emacs/git/emacs/emacs-28/nt/inc/stdint.h:24,
from C:/emacs/git/emacs/emacs-28/nt/inc/ms-w32.h:327,
from C:/emacs/git/emacs/emacs-28/src/conf_post.h:44,
from ../src/config.h:2726,
from C:/emacs/git/emacs/emacs-28/lib/fingerprint.c:20:
./stdint.h:89:5: error: #if with no expression
89 | #if
| ^
This appears to be caused by a change in "lib/stdint.h.in":
emacs-28/lib/stint.h.in: #if @GNULIBHEADERS_OVERRIDE_WINT_T@
master/lib/stint.h.in: #if @GNULIB_OVERRIDES_WINT_T@
emacs-28/configure.ac still has:
# Emacs does not use the wchar or wctype-h modules.
AC_DEFUN([gt_TYPE_WINT_T],
[GNULIB_OVERRIDES_WINT_T=0
AC_SUBST([GNULIB_OVERRIDES_WINT_T])])
It looks like this needs updating to use the new name.
AndyM
- bug#50985: Merging gnulib for Emacs 28.1?, Stefan Kangas, 2021/10/02
- bug#50985: Merging gnulib for Emacs 28.1?, Paul Eggert, 2021/10/03
- bug#50985: Merging gnulib for Emacs 28.1?, Paul Eggert, 2021/10/04
- bug#50985: Merging gnulib for Emacs 28.1?, Eli Zaretskii, 2021/10/04
- bug#50985: Merging gnulib for Emacs 28.1?, Paul Eggert, 2021/10/04
- bug#50985: Merging gnulib for Emacs 28.1?,
Andy Moreton <=
- bug#50985: Merging gnulib for Emacs 28.1?, Andy Moreton, 2021/10/04
- bug#50985: Merging gnulib for Emacs 28.1?, Ken Brown, 2021/10/05
- bug#50985: Merging gnulib for Emacs 28.1?, Eli Zaretskii, 2021/10/05
- bug#50985: Merging gnulib for Emacs 28.1?, Eli Zaretskii, 2021/10/05
- bug#50985: Merging gnulib for Emacs 28.1?, Robert Pluim, 2021/10/05
- bug#50985: Merging gnulib for Emacs 28.1?, Ken Brown, 2021/10/05
- bug#50985: Merging gnulib for Emacs 28.1?, Robert Pluim, 2021/10/05
- bug#50985: Merging gnulib for Emacs 28.1?, Paul Eggert, 2021/10/05
- bug#50985: Merging gnulib for Emacs 28.1?, Andy Moreton, 2021/10/05
- bug#50985: Merging gnulib for Emacs 28.1?, Robert Pluim, 2021/10/06