From e063da67902e2ba03cfc6f7381694f4c6a72ecf4 Mon Sep 17 00:00:00 2001 From: Pedro Alves Date: Tue, 17 Nov 2015 15:17:45 +0000 Subject: [C++] Define __STDC_CONSTANT_MACROS / __STDC_LIMIT_MACROS for stdint.h With some toolchains, building in C++ mode 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 ." # error "This file assumes that 'int' has exactly 32 bits. Please report your platform and compiler to ." ^ 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 ." #endif I see it when 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)), Simon reports seeing this on several cross compilers too. 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-17 Pedro Alves * common/common-defs.h (__STDC_CONSTANT_MACROS) (__STDC_LIMIT_MACROS): Define before including stdint.h. --- gdb/ChangeLog | 5 +++++ gdb/common/common-defs.h | 16 ++++++++++++++++ 2 files changed, 21 insertions(+) (limited to 'gdb') diff --git a/gdb/ChangeLog b/gdb/ChangeLog index fbfe4ad..d326b9c 100644 --- a/gdb/ChangeLog +++ b/gdb/ChangeLog @@ -1,5 +1,10 @@ 2015-11-17 Pedro Alves + * common/common-defs.h (__STDC_CONSTANT_MACROS) + (__STDC_LIMIT_MACROS): Define before including stdint.h. + +2015-11-17 Pedro Alves + * windows-nat.c (handle_exception): Return 0 for first chance exceptions. (get_windows_debug_event): Adjust. diff --git a/gdb/common/common-defs.h b/gdb/common/common-defs.h index 2be0d7d..548fe42 100644 --- a/gdb/common/common-defs.h +++ b/gdb/common/common-defs.h @@ -31,7 +31,23 @@ #include #include #include + +/* 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 1 +#define __STDC_LIMIT_MACROS 1 #include + #include #include #include -- cgit v1.1