Eli Zaretskii wrote:
But because string.h was included, __STRING_H_SOURCED__ is defined,
and MinGW's wchar.h doesn't define mbstate_t. Gnulib's wchar.h
I suggest adding a __STRING_H_SOURCED__ check to Gnulib's lib/wchar.in.h's
complicated test for the special invocation convention.
> Cc: bug-gnulib@gnu.org
> From: Paul Eggert
> Date: Sun, 9 Oct 2016 10:35:14 -0700
>
> Eli Zaretskii wrote:
> > I'm not sure I understand how this is different from what
> > e.g. Gnulib's wchar.h already does. Can you point out the crucial
> > differences?
>
> Ah, I didn't look at lib/wchar.in
Eli Zaretskii wrote:
I'm not sure I understand how this is different from what
e.g. Gnulib's wchar.h already does. Can you point out the crucial
differences?
Ah, I didn't look at lib/wchar.in.h. Yes, it's already doing that, with a
complicated ifdef that is supposed to work on MinGW. It isn't
> From: Paul Eggert
> Cc: bug-gnulib@gnu.org
> Date: Sun, 9 Oct 2016 10:10:38 -0700
>
> Eli Zaretskii wrote:
> > I'm not sure what would be the best way of avoiding these errors
>
> The usual method is to alter the gnulib .h file so that it merely
> include_next's
> the system .h file when it
Eli Zaretskii wrote:
I'm not sure what would be the best way of avoiding these errors
The usual method is to alter the gnulib .h file so that it merely include_next's
the system .h file when it detects that its partial inclusion is desired.
Something like this:
#ifdef __need_FILE
# @INCLUDE
Hi,
I recently upgraded to the latest version 3.22.2 of the MinGW runtime
from mingw.org. Building GDB 7.12 with the updated system headers
produces many compilation errors of the following 2 kinds:
1. Problems with wchar.h:
gcc -DHAVE_CONFIG_H -I. -I../.././gnulib/import -I.. -O2 -gd
