all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
* Should Emacs 26 be portable to Glibc 2.28?
@ 2018-03-08  2:09 Paul Eggert
  2018-03-08 13:39 ` Eli Zaretskii
  0 siblings, 1 reply; 3+ messages in thread
From: Paul Eggert @ 2018-03-08  2:09 UTC (permalink / raw)
  To: Emacs development discussions

[-- 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.  */
 

^ permalink raw reply related	[flat|nested] 3+ messages in thread

* Re: Should Emacs 26 be portable to Glibc 2.28?
  2018-03-08  2:09 Should Emacs 26 be portable to Glibc 2.28? Paul Eggert
@ 2018-03-08 13:39 ` Eli Zaretskii
  2018-03-09  1:11   ` Paul Eggert
  0 siblings, 1 reply; 3+ messages in thread
From: Eli Zaretskii @ 2018-03-08 13:39 UTC (permalink / raw)
  To: Paul Eggert; +Cc: emacs-devel

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



^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: Should Emacs 26 be portable to Glibc 2.28?
  2018-03-08 13:39 ` Eli Zaretskii
@ 2018-03-09  1:11   ` Paul Eggert
  0 siblings, 0 replies; 3+ messages in thread
From: Paul Eggert @ 2018-03-09  1:11 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: Gnulib bugs, emacs-devel

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




^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2018-03-09  1:11 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2018-03-08  2:09 Should Emacs 26 be portable to Glibc 2.28? Paul Eggert
2018-03-08 13:39 ` Eli Zaretskii
2018-03-09  1:11   ` Paul Eggert

Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.