Re: Should Emacs 26 be portable to Glibc 2.28?

[Eli Zaretskii]

> From: Paul Eggert <address@hidden>
> 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.