[PATCH 07/11] [C++/mingw] Define __STDC_CONSTANT_MACROS / __STDC_LIMIT_MACROS for stdint.h
Simon Marchi
simon.marchi@ericsson.com
Mon Nov 2 20:47:00 GMT 2015
On 15-11-02 02:36 PM, Pedro Alves wrote:
> Cross building for --host=x86_64-w64-mingw32 using Fedora 20's g++
> (gcc version 4.8.4 20141219 (Fedora MinGW 4.8.4-1.fc20)), stumbles on
> many instances of:
>
> In file included from ../../src/gdb/../include/splay-tree.h:43:0,
> from ../../src/gdb/dcache.c:26:
> build-gnulib/import/inttypes.h:61:3: error: #error "This file assumes that 'int' has exactly 32 bits. Please report your platform and compiler to <bug-gnulib@gnu.org>."
> # error "This file assumes that 'int' has exactly 32 bits. Please report your platform and compiler to <bug-gnulib@gnu.org>."
> ^
> make: *** [dcache.o] Error 1
>
> That's:
>
> #if !(INT_MIN == INT32_MIN && INT_MAX == INT32_MAX)
> # error "This file assumes that 'int' has exactly 32 bits. Please report your platform and compiler to <bug-gnulib@gnu.org>."
> #endif
>
> The issue is that on some hosts that predate C++11, when using C++ one
> must define __STDC_CONSTANT_MACROS/__STDC_LIMIT_MACROS to make visible
> the definitions of INTMAX_C / INTMAX_MAX etc.
>
> This was a C99 requirement that later C++11 -- the first to define
> stdint.h -- removed, and then C11 removed it as well.
>
> https://www.gnu.org/software/gnulib/manual/html_node/stdint_002eh.html
> says that gnulib's stdint.h fixes this, but because we run gnulib's
> configure tests with a C compiler, gnulib determines that mingw's
> stdint.h is C99-compliant, and doesn't actually replace it. Actually,
> even though configuring gnulib with a C++ compiler does result in
> gnulib replacing stdint.h, the resulting replacement is broken for
> mingw, because it defines uintptr_t incorrectly. I sent a gnulib
> patch upstream to fix that, here:
>
> https://lists.gnu.org/archive/html/bug-gnulib/2015-11/msg00004.html
>
> but then even with that, gnulib still stumbles on other
> configured-with-C++-compiler problems.
>
> So for now, until gnulib + C++ is fixed upstream and then gdb's copy
> is updated, which may take a while, I think it's best to keep
> configuring gnulib in C, and define
> __STDC_LIMIT_MACROS/__STDC_CONSTANT_MACROS ourselves, just like C99
> intended.
>
> gdb/ChangeLog:
> 2015-11-01 Pedro Alves <palves@redhat.com>
>
> * common/common-defs.h (__STDC_CONSTANT_MACROS)
> (__STDC_LIMIT_MACROS): Define before including stdint.h.
> ---
> gdb/common/common-defs.h | 16 ++++++++++++++++
> 1 file changed, 16 insertions(+)
>
> diff --git a/gdb/common/common-defs.h b/gdb/common/common-defs.h
> index 2be0d7d..59b1887 100644
> --- a/gdb/common/common-defs.h
> +++ b/gdb/common/common-defs.h
> @@ -31,7 +31,23 @@
> #include <stdio.h>
> #include <stdlib.h>
> #include <stddef.h>
> +
> +/* From:
> + https://www.gnu.org/software/gnulib/manual/html_node/stdint_002eh.html
> +
> + "On some hosts that predate C++11, when using C++ one must define
> + __STDC_CONSTANT_MACROS to make visible the definitions of constant
> + macros such as INTMAX_C, and one must define __STDC_LIMIT_MACROS to
> + make visible the definitions of limit macros such as INTMAX_MAX."
> +
> + gnulib doesn't fix this for us correctly yet. See:
> + https://lists.gnu.org/archive/html/bug-gnulib/2015-11/msg00004.html
> +
> + Meanwhile, explicitly define these ourselves, as C99 intended. */
> +#define __STDC_CONSTANT_MACROS
> +#define __STDC_LIMIT_MACROS
> #include <stdint.h>
> +
> #include <string.h>
> #include <errno.h>
> #include <alloca.h>
>
FYI, I stumbled on the same problem when building for various architectures this weekend. I
generated some toolchains by using some of the Buildroot included configurations, which use
uclibc. I ended up defining those macros as well in CFLAGS. So that change can help for more
configurations than just mingw.
More information about the Gdb-patches
mailing list