| Message ID | 20181114132336.71049-1-raphael.kubo.da.costa@intel.com |
|---|---|
| State | Superseded |
| Headers | show |
| Series | [rocko] m4: Workaround gnulib's fseeko.c implementation | expand |
On 11/14/18 5:23 AM, Raphael Kubo da Costa wrote: > From: Khem Raj <raj.khem@gmail.com> > > exposed by glibc 2.28 for details see > https://lists.gnu.org/r/bug-gnulib/2018-03/msg00000.html > > (From OE-Core rev: acca7f964bf9c21f3777085563a7928b8246f17f) > > Signed-off-by: Khem Raj <raj.khem@gmail.com> > Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org> > Signed-off-by: Raphael Kubo da Costa <raphael.kubo.da.costa@intel.com> in in stable/rocko-nmut. Odd thing it, this is not in patchwork but the sumo version is. Thanks, Armin > --- > meta/recipes-devtools/m4/m4-1.4.18.inc | 1 + > .../m4-1.4.18-glibc-change-work-around.patch | 129 ++++++++++++++++++ > 2 files changed, 130 insertions(+) > create mode 100644 meta/recipes-devtools/m4/m4/m4-1.4.18-glibc-change-work-around.patch > > diff --git a/meta/recipes-devtools/m4/m4-1.4.18.inc b/meta/recipes-devtools/m4/m4-1.4.18.inc > index d7c8648577..1bce097c60 100644 > --- a/meta/recipes-devtools/m4/m4-1.4.18.inc > +++ b/meta/recipes-devtools/m4/m4-1.4.18.inc > @@ -9,6 +9,7 @@ LIC_FILES_CHKSUM = "file://COPYING;md5=d32239bcb673463ab874e80d47fae504\ > > SRC_URI += "file://ac_config_links.patch \ > file://remove-gets.patch \ > + file://m4-1.4.18-glibc-change-work-around.patch \ > " > > SRC_URI_append_class-target = "\ > diff --git a/meta/recipes-devtools/m4/m4/m4-1.4.18-glibc-change-work-around.patch b/meta/recipes-devtools/m4/m4/m4-1.4.18-glibc-change-work-around.patch > new file mode 100644 > index 0000000000..72e7ae2080 > --- /dev/null > +++ b/meta/recipes-devtools/m4/m4/m4-1.4.18-glibc-change-work-around.patch > @@ -0,0 +1,129 @@ > +update for glibc libio.h removal in 2.28+ > + > +see > +https://src.fedoraproject.org/rpms/m4/c/814d592134fad36df757f9a61422d164ea2c6c9b?branch=master > + > +Upstream-Status: Pending > +Signed-off-by: Khem Raj <raj.khem@gmail.com> > +Index: m4-1.4.18/lib/fflush.c > +=================================================================== > +--- m4-1.4.18.orig/lib/fflush.c > ++++ m4-1.4.18/lib/fflush.c > +@@ -33,7 +33,7 @@ > + #undef fflush > + > + > +-#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 */ > + > + /* Clear the stream's ungetc buffer, preserving the value of ftello (fp). */ > + static void > +@@ -72,7 +72,7 @@ clear_ungetc_buffer (FILE *fp) > + > + #endif > + > +-#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 */) > + > + # if (defined __sferror || defined __DragonFly__ || defined __ANDROID__) && defined __SNPT > + /* FreeBSD, NetBSD, OpenBSD, DragonFly, Mac OS X, Cygwin, Android */ > +@@ -148,7 +148,7 @@ rpl_fflush (FILE *stream) > + if (stream == NULL || ! freading (stream)) > + return fflush (stream); > + > +-#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 */ > + > + clear_ungetc_buffer_preserving_position (stream); > + > +Index: m4-1.4.18/lib/fpending.c > +=================================================================== > +--- m4-1.4.18.orig/lib/fpending.c > ++++ m4-1.4.18/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, Android */ > +Index: m4-1.4.18/lib/fpurge.c > +=================================================================== > +--- m4-1.4.18.orig/lib/fpurge.c > ++++ m4-1.4.18/lib/fpurge.c > +@@ -62,7 +62,7 @@ fpurge (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 */ > + fp->_IO_read_end = fp->_IO_read_ptr; > + fp->_IO_write_ptr = fp->_IO_write_base; > + /* Avoid memory leak when there is an active ungetc buffer. */ > +Index: m4-1.4.18/lib/freadahead.c > +=================================================================== > +--- m4-1.4.18.orig/lib/freadahead.c > ++++ m4-1.4.18/lib/freadahead.c > +@@ -25,7 +25,7 @@ > + size_t > + freadahead (FILE *fp) > + { > +-#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 */ > + if (fp->_IO_write_ptr > fp->_IO_write_base) > + return 0; > + return (fp->_IO_read_end - fp->_IO_read_ptr) > +Index: m4-1.4.18/lib/freading.c > +=================================================================== > +--- m4-1.4.18.orig/lib/freading.c > ++++ m4-1.4.18/lib/freading.c > +@@ -31,7 +31,7 @@ freading (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->_flags & _IO_NO_WRITES) != 0 > + || ((fp->_flags & (_IO_NO_READS | _IO_CURRENTLY_PUTTING)) == 0 > + && fp->_IO_read_base != NULL)); > +Index: m4-1.4.18/lib/fseeko.c > +=================================================================== > +--- m4-1.4.18.orig/lib/fseeko.c > ++++ m4-1.4.18/lib/fseeko.c > +@@ -47,7 +47,7 @@ fseeko (FILE *fp, off_t offset, int when > + #endif > + > + /* These tests are based on fpurge.c. */ > +-#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 */ > + if (fp->_IO_read_end == fp->_IO_read_ptr > + && fp->_IO_write_ptr == fp->_IO_write_base > + && fp->_IO_save_base == NULL) > +@@ -123,7 +123,7 @@ fseeko (FILE *fp, off_t offset, int when > + return -1; > + } > + > +-#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 */ > + fp->_flags &= ~_IO_EOF_SEEN; > + fp->_offset = pos; > + #elif defined __sferror || defined __DragonFly__ || defined __ANDROID__ > +Index: m4-1.4.18/lib/stdio-impl.h > +=================================================================== > +--- m4-1.4.18.orig/lib/stdio-impl.h > ++++ m4-1.4.18/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. */ > + -- _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
akuster808 <akuster808@gmail.com> writes: > On 11/14/18 5:23 AM, Raphael Kubo da Costa wrote: > >> From: Khem Raj <raj.khem@gmail.com> >> >> exposed by glibc 2.28 for details see >> https://lists.gnu.org/r/bug-gnulib/2018-03/msg00000.html >> >> (From OE-Core rev: acca7f964bf9c21f3777085563a7928b8246f17f) >> >> Signed-off-by: Khem Raj <raj.khem@gmail.com> >> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org> >> Signed-off-by: Raphael Kubo da Costa <raphael.kubo.da.costa@intel.com> > > in in stable/rocko-nmut. Odd thing it, this is not in patchwork but the > sumo version is. Thanks. I need a few more patches to get host tools to build here on Fedora 29, but now I'm even more confused as to where to send them :-) What's the relationship between the -next, -nmut and -nmut2 branches in Yocto's poky-contrib? How do they interact with oe-core's -next branches? And what's the process for merging them into the actual stable branches? -- _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
On Fri, Nov 16, 2018 at 7:51 AM Raphael Kubo da Costa <raphael.kubo.da.costa@intel.com> wrote: > > akuster808 <akuster808@gmail.com> writes: > > > On 11/14/18 5:23 AM, Raphael Kubo da Costa wrote: > > > >> From: Khem Raj <raj.khem@gmail.com> > >> > >> exposed by glibc 2.28 for details see > >> https://lists.gnu.org/r/bug-gnulib/2018-03/msg00000.html > >> > >> (From OE-Core rev: acca7f964bf9c21f3777085563a7928b8246f17f) > >> > >> Signed-off-by: Khem Raj <raj.khem@gmail.com> > >> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org> > >> Signed-off-by: Raphael Kubo da Costa <raphael.kubo.da.costa@intel.com> > > > > in in stable/rocko-nmut. Odd thing it, this is not in patchwork but the > > sumo version is. > > Thanks. I need a few more patches to get host tools to build here on > Fedora 29, but now I'm even more confused as to where to send them :-) > > What's the relationship between the -next, -nmut and -nmut2 branches in > Yocto's poky-contrib? How do they interact with oe-core's -next > branches? And what's the process for merging them into the actual stable > branches? they are staging private branches used by maintainers. Eventually they should show up in <release>-next and then into <release> branch > -- > _______________________________________________ > Openembedded-core mailing list > Openembedded-core@lists.openembedded.org > http://lists.openembedded.org/mailman/listinfo/openembedded-core -- _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
On Fri, 2018-11-16 at 09:05 -0800, Khem Raj wrote: > On Fri, Nov 16, 2018 at 7:51 AM Raphael Kubo da Costa > <raphael.kubo.da.costa@intel.com> wrote: > > What's the relationship between the -next, -nmut and -nmut2 > > branches in Yocto's poky-contrib? How do they interact with oe- > > core's -next branches? And what's the process for merging them into > > the actual stable branches? > > they are staging private branches used by maintainers. Eventually > they should show up in <release>-next and then into <release> branch Right, and how do I know which and whose branch(es) to check for before sending a backport (or even to track in case I just want things to work locally)? -- _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
On Fri, 16 Nov 2018 at 17:16, Kubo Da Costa, Raphael <raphael.kubo.da.costa@intel.com> wrote: > On Fri, 2018-11-16 at 09:05 -0800, Khem Raj wrote: > > On Fri, Nov 16, 2018 at 7:51 AM Raphael Kubo da Costa > > <raphael.kubo.da.costa@intel.com> wrote: > > > What's the relationship between the -next, -nmut and -nmut2 > > > branches in Yocto's poky-contrib? How do they interact with oe- > > > core's -next branches? And what's the process for merging them into > > > the actual stable branches? > > > > they are staging private branches used by maintainers. Eventually > > they should show up in <release>-next and then into <release> branch > > Right, and how do I know which and whose branch(es) to check for before > sending a backport (or even to track in case I just want things to work > locally)? You can be excused for not checking the maintainer's private branches, so just check the release branch. If there's a patch in one the maintainer may point it out to keep you informed, feel free to review it to verify what is scheduled to be merged is complete. Ross -- _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
On Fri, Nov 16, 2018 at 9:16 AM Kubo Da Costa, Raphael <raphael.kubo.da.costa@intel.com> wrote: > > On Fri, 2018-11-16 at 09:05 -0800, Khem Raj wrote: > > On Fri, Nov 16, 2018 at 7:51 AM Raphael Kubo da Costa > > <raphael.kubo.da.costa@intel.com> wrote: > > > What's the relationship between the -next, -nmut and -nmut2 > > > branches in Yocto's poky-contrib? How do they interact with oe- > > > core's -next branches? And what's the process for merging them into > > > the actual stable branches? > > > > they are staging private branches used by maintainers. Eventually > > they should show up in <release>-next and then into <release> branch > > Right, and how do I know which and whose branch(es) to check for before > sending a backport (or even to track in case I just want things to work > locally)? thats just the maintainers process and usually leave them to do that. just tracking -next is probably better unless I want to be nosy :), maintainers replying to an email pointing to the pvt branch is sheer out of love to let you know where the patch stands as of now. -- _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
diff --git a/meta/recipes-devtools/m4/m4-1.4.18.inc b/meta/recipes-devtools/m4/m4-1.4.18.inc index d7c8648577..1bce097c60 100644 --- a/meta/recipes-devtools/m4/m4-1.4.18.inc +++ b/meta/recipes-devtools/m4/m4-1.4.18.inc @@ -9,6 +9,7 @@ LIC_FILES_CHKSUM = "file://COPYING;md5=d32239bcb673463ab874e80d47fae504\ SRC_URI += "file://ac_config_links.patch \ file://remove-gets.patch \ + file://m4-1.4.18-glibc-change-work-around.patch \ " SRC_URI_append_class-target = "\ diff --git a/meta/recipes-devtools/m4/m4/m4-1.4.18-glibc-change-work-around.patch b/meta/recipes-devtools/m4/m4/m4-1.4.18-glibc-change-work-around.patch new file mode 100644 index 0000000000..72e7ae2080 --- /dev/null +++ b/meta/recipes-devtools/m4/m4/m4-1.4.18-glibc-change-work-around.patch @@ -0,0 +1,129 @@ +update for glibc libio.h removal in 2.28+ + +see +https://src.fedoraproject.org/rpms/m4/c/814d592134fad36df757f9a61422d164ea2c6c9b?branch=master + +Upstream-Status: Pending +Signed-off-by: Khem Raj <raj.khem@gmail.com> +Index: m4-1.4.18/lib/fflush.c +=================================================================== +--- m4-1.4.18.orig/lib/fflush.c ++++ m4-1.4.18/lib/fflush.c +@@ -33,7 +33,7 @@ + #undef fflush + + +-#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 */ + + /* Clear the stream's ungetc buffer, preserving the value of ftello (fp). */ + static void +@@ -72,7 +72,7 @@ clear_ungetc_buffer (FILE *fp) + + #endif + +-#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 */) + + # if (defined __sferror || defined __DragonFly__ || defined __ANDROID__) && defined __SNPT + /* FreeBSD, NetBSD, OpenBSD, DragonFly, Mac OS X, Cygwin, Android */ +@@ -148,7 +148,7 @@ rpl_fflush (FILE *stream) + if (stream == NULL || ! freading (stream)) + return fflush (stream); + +-#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 */ + + clear_ungetc_buffer_preserving_position (stream); + +Index: m4-1.4.18/lib/fpending.c +=================================================================== +--- m4-1.4.18.orig/lib/fpending.c ++++ m4-1.4.18/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, Android */ +Index: m4-1.4.18/lib/fpurge.c +=================================================================== +--- m4-1.4.18.orig/lib/fpurge.c ++++ m4-1.4.18/lib/fpurge.c +@@ -62,7 +62,7 @@ fpurge (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 */ + fp->_IO_read_end = fp->_IO_read_ptr; + fp->_IO_write_ptr = fp->_IO_write_base; + /* Avoid memory leak when there is an active ungetc buffer. */ +Index: m4-1.4.18/lib/freadahead.c +=================================================================== +--- m4-1.4.18.orig/lib/freadahead.c ++++ m4-1.4.18/lib/freadahead.c +@@ -25,7 +25,7 @@ + size_t + freadahead (FILE *fp) + { +-#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 */ + if (fp->_IO_write_ptr > fp->_IO_write_base) + return 0; + return (fp->_IO_read_end - fp->_IO_read_ptr) +Index: m4-1.4.18/lib/freading.c +=================================================================== +--- m4-1.4.18.orig/lib/freading.c ++++ m4-1.4.18/lib/freading.c +@@ -31,7 +31,7 @@ freading (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->_flags & _IO_NO_WRITES) != 0 + || ((fp->_flags & (_IO_NO_READS | _IO_CURRENTLY_PUTTING)) == 0 + && fp->_IO_read_base != NULL)); +Index: m4-1.4.18/lib/fseeko.c +=================================================================== +--- m4-1.4.18.orig/lib/fseeko.c ++++ m4-1.4.18/lib/fseeko.c +@@ -47,7 +47,7 @@ fseeko (FILE *fp, off_t offset, int when + #endif + + /* These tests are based on fpurge.c. */ +-#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 */ + if (fp->_IO_read_end == fp->_IO_read_ptr + && fp->_IO_write_ptr == fp->_IO_write_base + && fp->_IO_save_base == NULL) +@@ -123,7 +123,7 @@ fseeko (FILE *fp, off_t offset, int when + return -1; + } + +-#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 */ + fp->_flags &= ~_IO_EOF_SEEN; + fp->_offset = pos; + #elif defined __sferror || defined __DragonFly__ || defined __ANDROID__ +Index: m4-1.4.18/lib/stdio-impl.h +=================================================================== +--- m4-1.4.18.orig/lib/stdio-impl.h ++++ m4-1.4.18/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. */ +