Should Emacs 26 be portable to Glibc 2.28?

Should Emacs 26 be portable to Glibc 2.28?

[Paul Eggert]

[-- Attachment #1: Type: text/plain, Size: 685 bytes --]

The attached patch, which I've installed into Emacs master, fixes a 
incompatibility between Emacs and the planned 2.28 release of glibc. 
Should I install it into the emacs-26 branch? glibc 2.28 is currently 
scheduled for August, so this shouldn't be much of an issue until then; 
however, as the patch is reasonably conservative and it's likely there 
won't be another Emacs release before August, it might make sense to 
install this patch into the emacs-26 branch now.

The underlying problem is that Emacs (via gnulib) mucks with glibc 
internals that are planned to change in glibc 2.28. For more see the 
thread here:

https://lists.gnu.org/r/bug-gnulib/2018-03/msg00000.html


[-- Attachment #2: t.patch --]
[-- Type: text/x-patch, Size: 1326 bytes --]

diff --git a/lib/fpending.c b/lib/fpending.c
index c84e3a5b4e..789f50e4e4 100644
--- a/lib/fpending.c
+++ b/lib/fpending.c
@@ -32,7 +32,7 @@ __fpending (FILE *fp)
   /* Most systems provide FILE as a struct and the necessary bitmask in
      <stdio.h>, because they need it for implementing getc() and putc() as
      fast macros.  */
-#if defined _IO_ftrylockfile || __GNU_LIBRARY__ == 1 /* GNU libc, BeOS, Haiku, Linux libc5 */
+#if defined _IO_EOF_SEEN || __GNU_LIBRARY__ == 1 /* GNU libc, BeOS, Haiku, Linux libc5 */
   return fp->_IO_write_ptr - fp->_IO_write_base;
 #elif defined __sferror || defined __DragonFly__ || defined __ANDROID__
   /* FreeBSD, NetBSD, OpenBSD, DragonFly, Mac OS X, Cygwin, Minix 3, Android */
diff --git a/lib/stdio-impl.h b/lib/stdio-impl.h
index 78d896e9f5..05c5752a24 100644
--- a/lib/stdio-impl.h
+++ b/lib/stdio-impl.h
@@ -18,6 +18,12 @@
    the same implementation of stdio extension API, except that some fields
    have different naming conventions, or their access requires some casts.  */
 
+/* Glibc 2.28 made _IO_IN_BACKUP private.  For now, work around this
+   problem by defining it ourselves.  FIXME: Do not rely on glibc
+   internals.  */
+#if !defined _IO_IN_BACKUP && defined _IO_EOF_SEEN
+# define _IO_IN_BACKUP 0x100
+#endif
 
 /* BSD stdio derived implementations.  */
 

Re: Should Emacs 26 be portable to Glibc 2.28?

[Eli Zaretskii]

> From: Paul Eggert <eggert@cs.ucla.edu>
> Date: Wed, 7 Mar 2018 18:09:49 -0800
> 
> The attached patch, which I've installed into Emacs master, fixes a 
> incompatibility between Emacs and the planned 2.28 release of glibc. 
> Should I install it into the emacs-26 branch? glibc 2.28 is currently 
> scheduled for August, so this shouldn't be much of an issue until then; 
> however, as the patch is reasonably conservative and it's likely there 
> won't be another Emacs release before August, it might make sense to 
> install this patch into the emacs-26 branch now.
> 
> The underlying problem is that Emacs (via gnulib) mucks with glibc 
> internals that are planned to change in glibc 2.28. For more see the 
> thread here:
> 
> https://lists.gnu.org/r/bug-gnulib/2018-03/msg00000.html

Thanks.

In the name of paranoia, would it be possible to make the first of
these two changes backward-compatible, by doing this instead:

> diff --git a/lib/fpending.c b/lib/fpending.c
> index c84e3a5b4e..789f50e4e4 100644
> --- a/lib/fpending.c
> +++ b/lib/fpending.c
> @@ -32,7 +32,7 @@ __fpending (FILE *fp)
>    /* Most systems provide FILE as a struct and the necessary bitmask in
>       <stdio.h>, because they need it for implementing getc() and putc() as
>       fast macros.  */
> -#if defined _IO_ftrylockfile || __GNU_LIBRARY__ == 1 /* GNU libc, BeOS, Haiku, Linux libc5 */
> +#if defined _IO_ftrylockfile || defined _IO_EOF_SEEN || __GNU_LIBRARY__ == 1 /* GNU libc, BeOS, Haiku, Linux libc5 */
>    return fp->_IO_write_ptr - fp->_IO_write_base;
>  #elif defined __sferror || defined __DragonFly__ || defined __ANDROID__
>    /* FreeBSD, NetBSD, OpenBSD, DragonFly, Mac OS X, Cygwin, Minix 3, Android */

With that, I think we can safely install this on the release branch.

Re: Should Emacs 26 be portable to Glibc 2.28?

[Paul Eggert]

On 03/08/2018 05:39 AM, Eli Zaretskii wrote:
> -#if defined _IO_ftrylockfile || __GNU_LIBRARY__ == 1 /* GNU libc, BeOS, Haiku, Linux libc5 */
> +#if defined _IO_ftrylockfile || defined _IO_EOF_SEEN || __GNU_LIBRARY__ == 1 /* GNU libc, BeOS, Haiku, Linux libc5 */

Thanks, good suggestion, I installed that into Gnulib[1] and copied it 
into Emacs master[2].

However, after looking into this some more it turns out that we need not 
backport it to emacs-26. For Emacs built with Glibc, fpending.c is 
compiled only for glibc 2.1.92 and older, which means that the 
portability bug with glibc 2.28 cannot be triggered for Emacs. Sorry 
about the false alarm.

[1] 
https://git.savannah.gnu.org/cgit/gnulib.git/commit/?id=74d9d6a293d7462dea8f83e7fc5ac792e956a0ad

[2] 
https://git.savannah.gnu.org/cgit/emacs.git/commit/?id=f0c590b857415e94a8ed9ded0e9ba2f91ea2a3c7