bug-gnu-emacs
[Top][All Lists]
Advanced

[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:44:01 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (windows-nt)

On Tue 05 Oct 2021, Andy Moreton wrote:

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

...and a similar fix is also needed to "lib/gnulib.mk.in". That gets
further through the build, but then fails with a link error:

  CCLD     temacs.exe
C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.3.0/../../../../x86_64-w64-mingw32/bin/ld.exe:
 comp.o: in function `comp_hash_source_file':
C:/emacs/git/emacs/emacs-28/src/comp.c:725: undefined reference to `md5_stream'
collect2.exe: error: ld returned 1 exit status
make[1]: *** [Makefile:647: temacs.exe] Error 1
make[1]: Leaving directory 
'/c/emacs/git/emacs/emacs-28/build/mingw64-x86_64-O2-native/src'
make: *** [Makefile:449: src] Error 2

That looks like relying on something that has moved to a different
gnulib module, or the native compiler code will need some adjustment.

    AndyM






reply via email to

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