[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Compilation warnings on MinGW due to Gnulib's wcwidth
From: |
Eli Zaretskii |
Subject: |
Re: Compilation warnings on MinGW due to Gnulib's wcwidth |
Date: |
Sat, 20 Jun 2015 10:47:36 +0300 |
> Date: Fri, 19 Jun 2015 15:03:17 +0100
> From: Gavin Smith <address@hidden>
> Cc: address@hidden, address@hidden
>
> It's very hard for me to guess what might be going on on your system.
> I suggest adding warning directives to wchar.h, like the following:
>
> Index: gnulib/lib/wchar.in.h
> ===================================================================
> --- gnulib/lib/wchar.in.h (revision 6344)
> +++ gnulib/lib/wchar.in.h (working copy)
> @@ -43,10 +43,12 @@
> the latter includes <wchar.h>. But here, we have no way to detect
> whether
> <wctype.h> is completely included or is still being included. */
>
> +#warning "AAAAAAAA"
> address@hidden@ @NEXT_WCHAR_H@
>
> #else
> /* Normal invocation convention. */
> +#warning "BBBBBBBBBBB"
>
> #ifndef address@hidden@_WCHAR_H
>
> which would confirm which parts of the file were being included, and
> the files that were being included at the time, e.g.:
Thanks for the suggestion.
The problem is indeed here:
#if defined __need_mbstate_t || defined __need_wint_t || (defined __hpux &&
((defined _INTTYPES_INCLUDED && !defined strtoimax) || defined
_GL_JUST_INCLUDE_SYSTEM_WCHAR_H)) || defined _GL_ALREADY_INCLUDING_WCHAR_H
This condition uses __need_wint_t as a means to decide whether or not
to include the system wchar.h directly. But some of the MinGW system
headers (ctype.h, stdio.h, stdint.h, and wctype.h, as well as wchar.h)
use that symbol. So, depending on whether one of these system headers
was included before wchar.h, the Gnulib's wchar.h bypasses or doesn't
bypass the declaration of wcwidth (and all the rest of the Gnulib's
wchar.h).
The comment below this condition indicates that these symbols are
there to test whether we are "Inside glibc and uClibc header files".
So I suggest to test those symbols only when we are indeed inside
headers of those libraries. I don't know how to test that, so instead
I added a condition of not being in MinGW:
#if ((defined __need_mbstate_t || defined __need_wint_t) && !defined
__MINGW32__) || (defined __hpux && ((defined _INTTYPES_INCLUDED && !defined
strtoimax) || defined _GL_JUST_INCLUDE_SYSTEM_WCHAR_H)) || defined
_GL_ALREADY_INCLUDING_WCHAR_H
And this solved the issue. There are now no warnings about wcwidth.
- Compilation warnings on MinGW due to Gnulib's wcwidth, Eli Zaretskii, 2015/06/18
- Re: Compilation warnings on MinGW due to Gnulib's wcwidth, Gavin Smith, 2015/06/18
- Re: Compilation warnings on MinGW due to Gnulib's wcwidth, Eli Zaretskii, 2015/06/19
- Re: Compilation warnings on MinGW due to Gnulib's wcwidth, Gavin Smith, 2015/06/19
- Re: Compilation warnings on MinGW due to Gnulib's wcwidth, Gavin Smith, 2015/06/19
- Re: Compilation warnings on MinGW due to Gnulib's wcwidth, Eli Zaretskii, 2015/06/19
- Re: Compilation warnings on MinGW due to Gnulib's wcwidth, Gavin Smith, 2015/06/19
- Re: Compilation warnings on MinGW due to Gnulib's wcwidth, Eli Zaretskii, 2015/06/20
- Re: Compilation warnings on MinGW due to Gnulib's wcwidth, Gavin Smith, 2015/06/19
- Re: Compilation warnings on MinGW due to Gnulib's wcwidth,
Eli Zaretskii <=
- Re: Compilation warnings on MinGW due to Gnulib's wcwidth, Paul Eggert, 2015/06/21
- Re: Compilation warnings on MinGW due to Gnulib's wcwidth, Eli Zaretskii, 2015/06/20