On 01/05/2015 04:03 PM, Eric Blake wrote: > Commit cf88e56ab broke the use of PRIdMAX and friends on modern > mingw64 installations. Basically, when requesting > _USE_MINGW_ANSI_STDIO, not only does mingw turn on support for %lld, > it also rewrites <inttypes.h> to provide PRIdMAX as "lld" instead of > "I64d" (but only when <stdio.h> is also included). But if a user is > NOT using the gnulib printf module, gnulib's <stdio.h> was still > giving printf() the system printf attribute, which causes the > compiler to then complain about an unknown %lld specifier, even though > we know we don't need to use the non-standard %I64d. So this patch > adds a configure-time probe that should work with older gcc (which > does not differentiate between printf flavors) and older mingw (where > _USE_MINGW_ANSI_STDIO has no impact on behavior), while fixing the > mismatch in flavors on modern systems. > > * m4/stdio_h.m4 (gl_STDIO_H): Probe for printf flavor via inttypes. > * lib/stdio.in.h (_GL_ATTRIBUTE_FORMAT_PRINTF_SYSTEM): Use result > to work with modern mingw. > > Signed-off-by: Eric Blake <ebl...@redhat.com> > ---
> + 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
> + #include <stdio.h>
> + #include <inttypes.h>
> + findme PRIdMAX findme
Blech. gcc 5.1 breaks this. With gcc 4.x (such as on Fedora 21), the
tail of the preprocessor output is:
# 5 "<stdin>" 2
findme "lld" findme
but with new gcc's enhanced ability to track which macro expansions came
from system headers [1] (such as on rawhide), output is now:
# 5 "<stdin>" 2
findme
# 5 "<stdin>" 3 4
"lld"
# 5 "<stdin>"
findme
so I'm working on updating this test to work again. I don't think it is
portable to try and use 'gcc -P' :(
[1] https://gcc.gnu.org/gcc-5/porting_to.html
--
Eric Blake eblake redhat com +1-919-301-3266
Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
