[07/11,C++/mingw] Define __STDC_CONSTANT_MACROS / __STDC_LIMIT_MACROS for stdint.h

Message ID 1446492970-21432-8-git-send-email-palves@redhat.com
State New, archived
Headers

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

Simon Marchi Nov. 2, 2015, 8:47 p.m. UTC | #1
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.
  
Simon Marchi Nov. 3, 2015, 1:58 p.m. UTC | #2
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
  
Pedro Alves Nov. 3, 2015, 2:06 p.m. UTC | #3
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
  
Simon Marchi Nov. 3, 2015, 2:15 p.m. UTC | #4
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.
  

Patch

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>