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

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 50985 in the body.
You can then email your comments to 50985 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Stefan Kangas <stefan <at> marxist.se>
To: bug-gnu-emacs <at> gnu.org
Subject: Merging gnulib for Emacs 28.1?
Date: Sun, 3 Oct 2021 05:42:16 +0200

X-Debbugs-CC: eggert <at> cs.ucla.edu

AFAICT, the last merge of Gnulib was in January:

    commit 7c9841b8428edfbc369eccf54788b668d4b27328
    Author: Paul Eggert <eggert <at> cs.ucla.edu>
    Date:   Sat Jan 23 11:35:44 2021 -0800

        Update from Gnulib by running admin/merge-gnulib

Running admin/merge-gnulib also gives these new files:

     lib/realloc.c
     m4/malloc.m4
     m4/realloc.m4
     m4/year2038.m4

Should we merge the latest changes from Gnulib into the emacs-28
branch?  There seems to have been a fair bit of portability bug fixes,
but I don't know how important they are:

    https://git.savannah.gnu.org/cgit/gnulib.git/log/

Message #8 received at 50985 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Stefan Kangas <stefan <at> marxist.se>
Cc: 50985 <at> debbugs.gnu.org
Subject: Re: bug#50985: Merging gnulib for Emacs 28.1?
Date: Sun, 3 Oct 2021 12:37:38 -0700

On 10/2/21 8:42 PM, Stefan Kangas wrote:
> Should we merge the latest changes from Gnulib into the emacs-28
> branch?

Yes, as there have been a fair number of Gnulib changes that Emacs could 
use for the usual portability and correctness reasons. Among other 
things, emacs-28 currently doesn't build on Fedora 34 (the current 
Fedora release) when you configure with --enable-gcc-warnings.

In July Eli gave the OK for me to merge Gnulib (see Bug#33847) but 
unfortunately I put it off. I'll look into doing that now.

Message #11 received at 50985 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Stefan Kangas <stefan <at> marxist.se>
Cc: 50985 <at> debbugs.gnu.org
Subject: Re: bug#50985: Merging gnulib for Emacs 28.1?
Date: Sun, 3 Oct 2021 23:37:09 -0700

[Message part 1 (text/plain, inline)]

On 10/3/21 12:37 PM, Paul Eggert wrote:
> In July Eli gave the OK for me to merge Gnulib (see Bug#33847) but 
> unfortunately I put it off. I'll look into doing that now.

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.

As you can see from recent activity in the emacs-28 branch I have also 
fixed a few glitches that prevent Emacs from building on Fedora 34 if 
configured with --enable-gcc-warnings, or from building on draft C2x 
platforms; those fixes are small and are independent of the attached 
patches. The attached patches fix several more glitches of this sort. A 
few such glitches still remain; I plan to look into those after this 
patchset is installed.

[0001-Update-from-Gnulib.patch (text/x-patch, attachment)]

[0002-Port-recent-Gnulib-changes-to-MS-Windows.patch (text/x-patch, attachment)]

Message #14 received at 50985 <at> debbugs.gnu.org (full text, mbox):

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: Re: 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 ;-)

Message #17 received at 50985 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: stefan <at> marxist.se, 50985 <at> debbugs.gnu.org
Subject: Re: bug#50985: Merging gnulib for Emacs 28.1?
Date: Mon, 4 Oct 2021 15:26:24 -0700

On 10/4/21 05:19, Eli Zaretskii wrote:

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

OK, I installed it into emacs-28 with the following reworded NEWS item:

** There is a new configure option '--disable-year2038' to cause
Emacs to use only 32-bit time_t on platforms that have both 32- and
64-bit time_t.  This may help link Emacs to a library with ABI
requiring traditional 32-bit time_t.  This option currently affects
only 32-bit ARM and x86 running GNU/Linux with glibc 2.34 and later.
Emacs now defaults to 64-bit time_t on these platforms.

> 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 ;-)

Yes, there will surely be some glitches, and not just on MS-Windows. 
I'll send a brief word of warning to emacs-devel.

Message #20 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Andy Moreton <andrewjmoreton <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: Re: bug#50985: Merging gnulib for Emacs 28.1?
Date: Tue, 05 Oct 2021 00:18:11 +0100

On Mon 04 Oct 2021, Eli Zaretskii wrote:

>> 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 ;-)

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

Message #23 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Andy Moreton <andrewjmoreton <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: Re: bug#50985: Merging gnulib for Emacs 28.1?
Date: Tue, 05 Oct 2021 00:44:01 +0100

On Tue 05 Oct 2021, Andy Moreton wrote:

> On Mon 04 Oct 2021, Eli Zaretskii wrote:
>
>>> 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 ;-)
>
> 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

Message #26 received at 50985 <at> debbugs.gnu.org (full text, mbox):

From: Ken Brown <kbrown <at> cornell.edu>
To: Andy Moreton <andrewjmoreton <at> gmail.com>, 50985 <at> debbugs.gnu.org
Subject: Re: bug#50985: Merging gnulib for Emacs 28.1?
Date: Tue, 5 Oct 2021 08:44:27 -0400

On 10/4/2021 7:44 PM, Andy Moreton wrote:
>    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.

md5_stream has moved to a new file, md5-stream.c, which didn't get imported into 
emacs:

commit 439979c0004197d6e0dd67c7807f57edacdf8a0d
Author: Bruno Haible <bruno <at> clisp.org>
Date:   Sun Sep 19 01:35:19 2021 +0200

    md5: Clarify module to source relation.

    * lib/md5-stream.c: New file, extracted from lib/md5.c.
    * lib/md5.c: Don't include stdlib.h, unlocked-io.h.
    (BLOCKSIZE, md5_stream): Moved to md5-stream.c.
    * lib/md5.h: Tweak.
    * modules/crypto/md5 (Files): Add lib/md5-stream.c.
    (configure.ac): Don't define GL_COMPILE_CRYPTO_STREAM.
    (Makefile.am): Arrange to compile md5-stream.c.
    (Link): Mention $(LIB_CRYPTO).

Ken

Message #29 received at 50985 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Andy Moreton <andrewjmoreton <at> gmail.com>
Cc: 50985 <at> debbugs.gnu.org
Subject: Re: bug#50985: Merging gnulib for Emacs 28.1?
Date: Tue, 05 Oct 2021 15:58:05 +0300

> From: Andy Moreton <andrewjmoreton <at> gmail.com>
> Date: Tue, 05 Oct 2021 00:18:11 +0100
> 
>   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.

Thanks, I installed this and the other change you proposed, to allow
people build Emacs, until Paul fixes this "properly".

Message #32 received at 50985 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Andy Moreton <andrewjmoreton <at> gmail.com>
Cc: 50985 <at> debbugs.gnu.org
Subject: Re: bug#50985: Merging gnulib for Emacs 28.1?
Date: Tue, 05 Oct 2021 15:59:19 +0300

> From: Andy Moreton <andrewjmoreton <at> gmail.com>
> Date: Tue, 05 Oct 2021 00:44:01 +0100
> 
>   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.

md5_stream was moved to a separate file.  If someone knows how to
import that, please do; until then the native-compilation build will
fail.

Message #35 received at 50985 <at> debbugs.gnu.org (full text, mbox):

From: Robert Pluim <rpluim <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Andy Moreton <andrewjmoreton <at> gmail.com>, 50985 <at> debbugs.gnu.org
Subject: Re: bug#50985: Merging gnulib for Emacs 28.1?
Date: Tue, 05 Oct 2021 15:44:56 +0200

[Message part 1 (text/plain, inline)]

>>>>> On Tue, 05 Oct 2021 15:58:05 +0300, Eli Zaretskii <eliz <at> gnu.org> said:

    >> From: Andy Moreton <andrewjmoreton <at> gmail.com>
    >> Date: Tue, 05 Oct 2021 00:18:11 +0100
    >> 
    >> 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.

    Eli> Thanks, I installed this and the other change you proposed, to allow
    Eli> people build Emacs, until Paul fixes this "properly".

Hereʼs what I did to get it to build --with-native-compilation. Not
pushing, since no doubt my method and commit message are all wrong :-)

[0001-Unbreak-with-native-compilation-build-after-gnulib-u.patch (text/x-diff, attachment)]

[Message part 3 (text/plain, inline)]

Robert
-- 

Message #38 received at 50985 <at> debbugs.gnu.org (full text, mbox):

From: Ken Brown <kbrown <at> cornell.edu>
To: Robert Pluim <rpluim <at> gmail.com>, Eli Zaretskii <eliz <at> gnu.org>,
 Paul Eggert <eggert <at> cs.ucla.edu>
Cc: Andy Moreton <andrewjmoreton <at> gmail.com>, 50985 <at> debbugs.gnu.org
Subject: Re: bug#50985: Merging gnulib for Emacs 28.1?
Date: Tue, 5 Oct 2021 10:09:47 -0400

On 10/5/2021 9:44 AM, Robert Pluim wrote:
> Hereʼs what I did to get it to build --with-native-compilation. Not
> pushing, since no doubt my method and commit message are all wrong :-)

FWIW, I came up with essentially the same patch, using a much clumsier method.

One trivial remark:

> @@ -79,6 +90,7 @@
>  #  count-leading-zeros \
>  #  count-one-bits \
>  #  count-trailing-zeros \
> +#  crypto/md5 \
>  #  crypto/md5-buffer \
>  #  crypto/sha1-buffer \
>  #  crypto/sha256-buffer \

You can omit crypto/md5-buffer, since it's pulled in by crypto/md5.

Ken

Message #41 received at 50985 <at> debbugs.gnu.org (full text, mbox):

From: Robert Pluim <rpluim <at> gmail.com>
To: Ken Brown <kbrown <at> cornell.edu>
Cc: Eli Zaretskii <eliz <at> gnu.org>, Paul Eggert <eggert <at> cs.ucla.edu>,
 Andy Moreton <andrewjmoreton <at> gmail.com>, 50985 <at> debbugs.gnu.org
Subject: Re: bug#50985: Merging gnulib for Emacs 28.1?
Date: Tue, 05 Oct 2021 16:11:56 +0200

>>>>> On Tue, 5 Oct 2021 10:09:47 -0400, Ken Brown <kbrown <at> cornell.edu> said:

    Ken> On 10/5/2021 9:44 AM, Robert Pluim wrote:
    >> Hereʼs what I did to get it to build --with-native-compilation. Not
    >> pushing, since no doubt my method and commit message are all wrong :-)

    Ken> FWIW, I came up with essentially the same patch, using a much clumsier method.

    Ken> One trivial remark:

    >> @@ -79,6 +90,7 @@
    >> #  count-leading-zeros \
    >> #  count-one-bits \
    >> #  count-trailing-zeros \
    >> +#  crypto/md5 \
    >> #  crypto/md5-buffer \
    >> #  crypto/sha1-buffer \
    >> #  crypto/sha256-buffer \

    Ken> You can omit crypto/md5-buffer, since it's pulled in by crypto/md5.

Probably. When it comes to gnulib I prefer to leave it to people who
know what theyʼre doing :-)

Robert
-- 

Message #44 received at 50985 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Robert Pluim <rpluim <at> gmail.com>, Ken Brown <kbrown <at> cornell.edu>
Cc: Eli Zaretskii <eliz <at> gnu.org>, Andy Moreton <andrewjmoreton <at> gmail.com>,
 50985 <at> debbugs.gnu.org
Subject: Re: bug#50985: Merging gnulib for Emacs 28.1?
Date: Tue, 5 Oct 2021 09:16:13 -0700

[Message part 1 (text/plain, inline)]

On 10/5/21 7:11 AM, Robert Pluim wrote:
> Probably. When it comes to gnulib I prefer to leave it to people who
> know what theyʼre doing :-)

We can't wait for *that* (:-), so I charged ahead and installed the 
attached patches into the emacs-28 branch. This fixed the md5_stream 
issue for me.

The key issue here is whether Emacs wants to use cryptography algorithms 
supported by the Linux kernel, if available. I expect that Emacs doesn't 
want to bother, because its use of md5_stream is not that performance- 
or security-relevant and because if we wanted Emacs to use the kernel 
stuff that'd drag in a lot more Gnulib modules which would be more 
trouble than it's worth. Comments welcome of course, since this is a 
judgment call.

I hadn't run into this earlier because I was doing a default 
configure+build, which on my platform didn't use native compilation.

[0001-Tweak-recent-configure-fix.patch (text/x-patch, attachment)]

[0002-Fix-md5-issue-in-recent-Gnulib-merge.patch (text/x-patch, attachment)]

Message #47 received at 50985 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Ken Brown <kbrown <at> cornell.edu>, Robert Pluim <rpluim <at> gmail.com>,
 Eli Zaretskii <eliz <at> gnu.org>
Cc: Andy Moreton <andrewjmoreton <at> gmail.com>, 50985 <at> debbugs.gnu.org
Subject: Re: bug#50985: Merging gnulib for Emacs 28.1?
Date: Tue, 5 Oct 2021 09:19:27 -0700

On 10/5/21 7:09 AM, Ken Brown wrote:
> You can omit crypto/md5-buffer, since it's pulled in by crypto/md5.

emacs/src/fns.c uses md5_buffer directly, so I kept crypto/md5-buffer in 
admin/merge-gnulib's GNULIB_MODULES list. The idea is that 
GNULIB_MODULES says what Emacs needs directly, and that the rest of 
admin/merge-gnulib deduces the indirect dependencies.

Message #52 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Andy Moreton <andrewjmoreton <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: Re: bug#50985: Merging gnulib for Emacs 28.1?
Date: Tue, 05 Oct 2021 19:15:00 +0100

On Tue 05 Oct 2021, Paul Eggert wrote:

> On 10/5/21 7:11 AM, Robert Pluim wrote:
>> Probably. When it comes to gnulib I prefer to leave it to people who
>> know what theyʼre doing :-)
>
> We can't wait for *that* (:-), so I charged ahead and installed the attached
> patches into the emacs-28 branch. This fixed the md5_stream issue for me.
>
> The key issue here is whether Emacs wants to use cryptography algorithms
> supported by the Linux kernel, if available. I expect that Emacs doesn't want
> to bother, because its use of md5_stream is not that performance- or
> security-relevant and because if we wanted Emacs to use the kernel stuff
> that'd drag in a lot more Gnulib modules which would be more trouble than it's
> worth. Comments welcome of course, since this is a judgment call.
>
> I hadn't run into this earlier because I was doing a default configure+build,
> which on my platform didn't use native compilation.

Thanks building for native compilation from a clean checkout now work
for me for the emacs-28 branch.

The same issue with md5-stream now occurs on master, as the most recent
merge from emacs-28 to master did not pick up the md5-stream changes.

    AndyM

Message #55 received at 50985 <at> debbugs.gnu.org (full text, mbox):

From: Robert Pluim <rpluim <at> gmail.com>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: Eli Zaretskii <eliz <at> gnu.org>, Andy Moreton <andrewjmoreton <at> gmail.com>,
 50985 <at> debbugs.gnu.org, Ken Brown <kbrown <at> cornell.edu>
Subject: Re: bug#50985: Merging gnulib for Emacs 28.1?
Date: Wed, 06 Oct 2021 09:23:53 +0200

>>>>> On Tue, 5 Oct 2021 09:16:13 -0700, Paul Eggert <eggert <at> cs.ucla.edu> said:

    Paul> On 10/5/21 7:11 AM, Robert Pluim wrote:
    >> Probably. When it comes to gnulib I prefer to leave it to people who
    >> know what theyʼre doing :-)

    Paul> We can't wait for *that* (:-), so I charged ahead and installed the
    Paul> attached patches into the emacs-28 branch. This fixed the md5_stream
    Paul> issue for me.

Your patch just proves my point: mine was less minimal than it could
have been because I made a mistake in adding crypto/af_alg, then
removing it, and thus having an excessive addition to AVOIDED_MODULES.

    Paul> The key issue here is whether Emacs wants to use cryptography
    Paul> algorithms supported by the Linux kernel, if available. I expect that
    Paul> Emacs doesn't want to bother, because its use of md5_stream is not
    Paul> that performance- or security-relevant and because if we wanted Emacs
    Paul> to use the kernel stuff that'd drag in a lot more Gnulib modules which
    Paul> would be more trouble than it's worth. Comments welcome of course,
    Paul> since this is a judgment call.

Seems sound to me. --with-native-compilation works for me now on
GNU/Linux.

    Paul> I hadn't run into this earlier because I was doing a default
    Paul> configure+build, which on my platform didn't use native compilation.

I donʼt think any platform does native compilation by default (yet?).

Robert
-- 

Message #58 received at 50985 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Stefan Kangas <stefan <at> marxist.se>
Cc: eggert <at> cs.ucla.edu, 50985 <at> debbugs.gnu.org
Subject: Re: bug#50985: Merging gnulib for Emacs 28.1?
Date: Thu, 07 Oct 2021 11:14:55 +0200

gnulib has now been merged on both emacs-28 and on master, so I'm
closing this bug report.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Previous Next

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