On 21/05/15 00:26, Eric Blake wrote: > Per https://gcc.gnu.org/gcc-5/porting_to.html, gcc 5.1 intentionally > changed the preprocessor to emit multiple lines, rather than one > line, when expanding text that includes literal markers combined with > a macro expansion obtained from a header. This in turn breaks the > probe for whether mingw headers support GNU-style "lld" for PRIdMAX, > as the probe text was no longer on one line. > > While at it, I also noted that on 64-bit Linux, PRIdMAX is "ld". > > This patch changes from grepping preprocessor output (with its > indeterminate layout due to differences in preprocessors) to instead > grepping an object file with a witness string literal embedded. > > It feels a bit gross, and certainly costs more processor time to > compute, but I can't come up with anything better. > > Based on a report by Suren Hajyan. > > * m4/stdio_h.m4 (gl_STDIO_H): Change to compile test coupled with > grepping the object file, to work around new gcc preprocessor rules. > > Signed-off-by: Eric Blake <ebl...@redhat.com> > --- > > Any better ideas for how I can probe the value of PRIdMAX? > > Suren, I can work with you offline, to test a build of libvirt > that incorporates this gnulib patch to see if it helps resolve > your mingw cross-compilation of libvirt. > > ChangeLog | 6 ++++++ > m4/stdio_h.m4 | 19 +++++++++++++------ > 2 files changed, 19 insertions(+), 6 deletions(-) > > diff --git a/ChangeLog b/ChangeLog > index 293b863..1b67561 100644 > --- a/ChangeLog > +++ b/ChangeLog > @@ -1,3 +1,9 @@ > +2015-05-20 Eric Blake <ebl...@redhat.com> > + > + stdio: fix probe on mingw under gcc 5.1 > + * m4/stdio_h.m4 (gl_STDIO_H): Change to compile test coupled with > + grepping the object file, to work around new gcc preprocessor rules. > + > 2015-03-09 Eric Blake <ebl...@redhat.com> > > error: document all entry points provided > diff --git a/m4/stdio_h.m4 b/m4/stdio_h.m4 > index e0c4bde..8ba140b 100644 > --- a/m4/stdio_h.m4 > +++ b/m4/stdio_h.m4 > @@ -1,4 +1,4 @@ > -# stdio_h.m4 serial 44 > +# stdio_h.m4 serial 45 > dnl Copyright (C) 2007-2015 Free Software Foundation, Inc. > dnl This file is free software; the Free Software Foundation > dnl gives unlimited permission to copy and/or distribute it, > @@ -8,6 +8,7 @@ AC_DEFUN([gl_STDIO_H], > [ > dnl For __USE_MINGW_ANSI_STDIO > AC_REQUIRE([gl_USE_SYSTEM_EXTENSIONS]) > + AC_REQUIRE([AC_PROG_EGREP]) > > AC_REQUIRE([gl_STDIO_H_DEFAULTS]) > gl_NEXT_HEADERS([stdio.h]) > @@ -17,13 +18,19 @@ AC_DEFUN([gl_STDIO_H], > dnl printf wrapper the right attribute to match. > AC_CACHE_CHECK([whether inttypes macros match system or gnu printf], > [gl_cv_func_printf_attribute_flavor], > - [AC_EGREP_CPP([findme .(ll|j)d. findme], > - [#define __STDC_FORMAT_MACROS 1 > + [AC_COMPILE_IFELSE([AC_LANG_PROGRAM([[ > + #define __STDC_FORMAT_MACROS 1 > #include <stdio.h> > #include <inttypes.h> > - findme PRIdMAX findme > - ], [gl_cv_func_printf_attribute_flavor=gnu], > - [gl_cv_func_printf_attribute_flavor=system])]) > + extern int offset; > + static const char probe[] = "\nFiNdMe" PRIdMAX "fInDmE\n"; > + ]], [[ > + return !probe[offset];]])], > + [if $EGREP "FiNdMe(l?l|j)dfInDmE" conftest.$OBJEXT >/dev/null 2>&1; > then > + gl_cv_func_printf_attribute_flavor=gnu > + else > + gl_cv_func_printf_attribute_flavor=system > + fi], [gl_cv_func_printf_attribute_flavor=system])]) > if test "$gl_cv_func_printf_attribute_flavor" = gnu; then > AC_DEFINE([GNULIB_PRINTF_ATTRIBUTE_FLAVOR_GNU], [1], > [Define to 1 if printf and friends should be labeled with
It's a bit gross, though I can't see any problems with it. You could process the preprocessor output too with something like that, though it's not great either. cpp ... | sed /^#/d | tr -cd '[[:alnum:]]' | grep ... thanks, Pádraig
