Message ID | 1446492970-21432-8-git-send-email-palves@redhat.com |
---|---|
State | New, archived |
Headers |
Received: (qmail 36404 invoked by alias); 2 Nov 2015 19:44:40 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: <gdb-patches.sourceware.org> List-Unsubscribe: <mailto:gdb-patches-unsubscribe-##L=##H@sourceware.org> List-Subscribe: <mailto:gdb-patches-subscribe@sourceware.org> List-Archive: <http://sourceware.org/ml/gdb-patches/> List-Post: <mailto:gdb-patches@sourceware.org> List-Help: <mailto:gdb-patches-help@sourceware.org>, <http://sourceware.org/ml/#faqs> Sender: gdb-patches-owner@sourceware.org Delivered-To: mailing list gdb-patches@sourceware.org Received: (qmail 35222 invoked by uid 89); 2 Nov 2015 19:44:39 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=AWL, BAYES_00, SPF_HELO_PASS, T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Mon, 02 Nov 2015 19:44:38 +0000 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (Postfix) with ESMTPS id 39021C0B5934 for <gdb-patches@sourceware.org>; Mon, 2 Nov 2015 19:36:19 +0000 (UTC) Received: from brno.lan (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id tA2JaAQ0009459 for <gdb-patches@sourceware.org>; Mon, 2 Nov 2015 14:36:18 -0500 From: Pedro Alves <palves@redhat.com> To: gdb-patches@sourceware.org Subject: [PATCH 07/11] [C++/mingw] Define __STDC_CONSTANT_MACROS / __STDC_LIMIT_MACROS for stdint.h Date: Mon, 2 Nov 2015 19:36:06 +0000 Message-Id: <1446492970-21432-8-git-send-email-palves@redhat.com> In-Reply-To: <1446492970-21432-1-git-send-email-palves@redhat.com> References: <1446492970-21432-1-git-send-email-palves@redhat.com> |
Commit Message
Pedro Alves
Nov. 2, 2015, 7:36 p.m. UTC
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(+)
Comments
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.
On 15-11-02 03:47 PM, Simon Marchi wrote: > 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. Actually, would it be better to add ifndefs? #ifndef __STDC_CONSTANT_MACROS #define __STDC_CONSTANT_MACROS #endif (same for __STDC_LIMIT_MACROS) I tried to build the latest version of the branch, but since I had specified those in CFLAGS, I get: In file included from /home/simark/src/binutils-gdb/gdb/defs.h:28:0, from /home/simark/src/binutils-gdb/gdb/gdb.c:19: /home/simark/src/binutils-gdb/gdb/common/common-defs.h:47:0: error: "__STDC_CONSTANT_MACROS" redefined [-Werror] #define __STDC_CONSTANT_MACROS ^ <command-line>:0:0: note: this is the location of the previous definition In file included from /home/simark/src/binutils-gdb/gdb/defs.h:28:0, from /home/simark/src/binutils-gdb/gdb/gdb.c:19: /home/simark/src/binutils-gdb/gdb/common/common-defs.h:48:0: error: "__STDC_LIMIT_MACROS" redefined [-Werror] #define __STDC_LIMIT_MACROS ^ <command-line>:0:0: note: this is the location of the previous definition cc1plus: all warnings being treated as errors
On 11/03/2015 01:58 PM, Simon Marchi wrote: > On 15-11-02 03:47 PM, Simon Marchi wrote: >> 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. > > Actually, would it be better to add ifndefs? > > #ifndef __STDC_CONSTANT_MACROS > #define __STDC_CONSTANT_MACROS > #endif > > (same for __STDC_LIMIT_MACROS) > > I tried to build the latest version of the branch, but since I had specified those in CFLAGS, I get: Isn't this a case of "don't do that (CFLAGS), then" ? If I update the gnulib patch per Paul's comment here: https://lists.nongnu.org/archive/html/bug-gnulib/2015-11/msg00006.html then __STDC_CONSTANT_MACROS/__STDC_LIMIT_MACROS will be unconditionally defined in config.h; I don't think defines in config.h can be ifndefed. Thanks, Pedro Alves
On 15-11-03 09:06 AM, Pedro Alves wrote:
> Isn't this a case of "don't do that (CFLAGS), then" ?
Maybe. I was thinking somebody might have this defined in their
development environment, but I agree it's unlikely.
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>