Re: MinGW compilation errors with Gnulib wchar.h and wctype.h

> Cc: bug-gnulib@gnu.org > From: Paul Eggert > Date: Mon, 10 Oct 2016 08:07:35 -0700 > > Thanks, I installed that into Gnulib. Great, thanks a lot.

Re: MinGW compilation errors with Gnulib wchar.h and wctype.h

Thanks, I installed that into Gnulib.

Re: MinGW compilation errors with Gnulib wchar.h and wctype.h

> Cc: bug-gnulib@gnu.org > From: Paul Eggert > Date: Sun, 9 Oct 2016 11:07:46 -0700 > > 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 &g

Re: MinGW compilation errors with Gnulib wchar.h and wctype.h

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.

Re: MinGW compilation errors with Gnulib wchar.h and wctype.h

> 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 > >

Re: MinGW compilation errors with Gnulib wchar.h and wctype.h

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

Re: MinGW compilation errors with Gnulib wchar.h and wctype.h

fixups */ > #endif 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? > It would be nicer if MinGW didn't have the problem in question. They could do > that by altering their include-file practices. I agree. Thanks.

Re: MinGW compilation errors with Gnulib wchar.h and wctype.h

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

MinGW compilation errors with Gnulib wchar.h and wctype.h

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

wchar.h, wctype.h: fix wint_t on MSVC

The choice of wint_t on MSVC ('unsigned short') violates ISO C 99. We need to change it to 'unsigned int' instead. 2011-09-11 Bruno Haible Fix wint_t on MSVC. * lib/wchar.in.h (wint_t): On MSVC, override it. * lib/wctype.in.h (wint_t): Likewise. * m4/stdint.m4

Re: C++ compilation errors in wchar.h

On Fri, Apr 1, 2011 at 3:02 PM, Bruno Haible wrote: >> ../lib/wchar.h:751:27: error: invalid type in declaration before ';' token >> ../lib/wchar.h:751:27: error: 'int wmemchr' redeclared as different kind of >> symbol > > This appears to be a glibc

Re: C++ compilation errors in wchar.h

sts -I.. -DIN_LIBPOSIX_GNULIB_TESTS=1 -I. > -I../../tests -I.. -I../../tests/.. -I../lib -I../../tests/../lib-MT > test-wchar-c++.o -MD -MP -MF $depbase.Tpo -c -o test-wchar-c++.o > ../../tests/test-wchar-c++.cc &&\ > mv -f $depbase.Tpo $depbase.Po > In file included

Re: [PATCH] stdint: omit redundant check for wchar.h

Paul Eggert wrote: > * m4/stdint.m4 (gl_STDINT_H): The earlier part of this macro now > always tests whether wchar.h exists, so remove the now-redundant test. Thanks. I missed that. Btw, the doc is incomplete: In [1] and [2] we found two platforms on which WCHAR_MIN and WCHAR_MAX ar

[PATCH] stdint: omit redundant check for wchar.h

* m4/stdint.m4 (gl_STDINT_H): The earlier part of this macro now always tests whether wchar.h exists, so remove the now-redundant test. diff --git a/m4/stdint.m4 b/m4/stdint.m4 index 2b67952..e7d0d07 100644 --- a/m4/stdint.m4 +++ b/m4/stdint.m4 @@ -1,4 +1,4 @@ -# stdint.m4 serial 38 +# stdint.m4

Re: Bug in GNULIB wchar.h?

> OK to change the comment like this? Paul didn't comment or object. So I applied this. 2008-04-11 Bruno Haible <[EMAIL PROTECTED]> * lib/wchar.in.h: Tweak comment. > --- lib/wchar.in.h.orig 2008-03-31 13:05:33.0 +0200 > +++ lib/wchar.in.h2008-03-31 13:05:20.

Re: Bug in GNULIB wchar.h?

Paul Eggert wrote: > Thanks, I installed it into gnulib with this ChangeLog entry: > > 2008-03-30 Paul Eggert <[EMAIL PROTECTED]> > > * lib/wchar.in.h [defined __need_mbstate_t]: Just include . > Problem reported by Erik Benada in >

Re: Bug in GNULIB wchar.h?

Erik Benada <[EMAIL PROTECTED]> writes: > yes, this patch fixes my problem. Thanks, I installed it into gnulib with this ChangeLog entry: 2008-03-30 Paul Eggert <[EMAIL PROTECTED]> * lib/wchar.in.h [defined __need_mbstate_t]: Just include . Problem reported by Erik Benada in

Re: Bug in GNULIB wchar.h?

Does this patch fix your problem? 2008-03-29 Paul Eggert <[EMAIL PROTECTED]> * lib/wchar.in.h [defined __need_mbstate_t]: Just include wchar.h in this case. Problem reported by Erik Benada. diff --git a/lib/wchar.in.h b/lib/wchar.in.h index 924a338..d7a1b5d 100644 ---

Bug in GNULIB wchar.h?

buiter_multi' has no member named 'cur' mbuiter.h:137: error: 'struct mbuiter_multi' has no member named 'cur' mbuiter.h:138: error: 'struct mbuiter_multi' has no member named 'cur' It seems that mbstate_t is not declared. Uclibc was built

gnulib workaround for missing wchar.h on FreeBSD 4.2?

I'm trying to build a GNU toolchain on FreeBSD 4.2. Unfortunately this machine has no , which causes failures for anything trying to use this header, which usually show up in gnulib's replacement module (e.g. coreutils and m4 die when trying to '#include ""'). Is there already a gnulib patch fo

Re: older Linux wchar.h vs. gcc 4.3.x

Micah Cowan wrote: > Several years ago, I began work on explaining the differences between > C90, C99, and common vendor extensions; I never finished, but the > section on inline functions may be helpful: > http://micah.cowan.name/tech/c-changes.html#N0.238 Well, neither your writeup nor mine

Re: older Linux wchar.h vs. gcc 4.3.x

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Eric Blake wrote: > We will probably start seeing reports like this more frequently as gcc 4.3 is > adopted, especially since gnulib projects tend to prefer std=gnu99 when a gcc > compiler is detected. Can anyone think of a way to detect broken sy

Re: older Linux wchar.h vs. gcc 4.3.x

Eric Blake wrote: > the pair 'extern inline' that causes the problem. Are we stuck with just > telling these users that they shouldn't upgrade gcc without also upgrading > their headers, because the old headers are broken with the new gcc? When gcc changed the semantics they also introduced the

Re: older Linux wchar.h vs. gcc 4.3.x

Eric Blake wrote: > Can anyone think of a way to detect broken system > headers that were relying on 'extern inline', in such a way that we can make > the gnulib wrapper headers nuke those troublesome declarations out of the > headers? [1] contains a test case. How to modify the glibc headers,

older Linux wchar.h vs. gcc 4.3.x

If you aren't already aware, the (not-yet-released) gcc 4.3 is changing the semantics of 'extern inline' functions to obey C99 semantics when called with std=gnu99. The net result of this change is that functions declared in headers that relied on the old gcc semantics to be inline-only will no

Re: wchar.h

s I don't have access to OS X 10.4.6, I can't ascertain whether it is a valid report of failure in the MacOS wchar.h. - -- Don't work too hard, make some time for fun as well! Eric Blake [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (Cygwin) C

Re: wchar.h

Eric Blake wrote: > > and, perhaps, on whichever OS/X it is that needs the "runetype.h" > > > The bottom line is that there really is some flavor of OS/X that > > has this pre-include of "runetype.h" requirement out there somewhere. > > Is this patch okay to apply so that the existing wchar modul

Re: wchar.h

it is a matter of using the 'wchar' module, and in your code, #include "config.h" #include because gnulib makes sure that a replacement wchar.h, if needed, is found prior to the buggy system wchar.h. > > and, perhaps, on whichever OS/X it is that needs the "runetype

Re: wchar.h

Daniel Jacobowitz wrote: > On Sun, Feb 25, 2007 at 03:56:46PM +0100, Bruno Haible wrote: >> Daniel Jacobowitz wrote: >>> Paolo's updates added a check for runetype.h >>> in order to make Mac OS/X's work properly. Perhaps gnulib's >>> substitute

Re: wchar.h (was: Re: snprintfv, more gnulibification)

On Sun, Feb 25, 2007 at 03:56:46PM +0100, Bruno Haible wrote: > Daniel Jacobowitz wrote: > > Paolo's updates added a check for runetype.h > > in order to make Mac OS/X's work properly. Perhaps gnulib's > > substitute wchar.h ought to handle that? > &

wchar.h (was: Re: snprintfv, more gnulibification)

Daniel Jacobowitz wrote: > Paolo's updates added a check for runetype.h > in order to make Mac OS/X's work properly. Perhaps gnulib's > substitute wchar.h ought to handle that? For which version of Mac OS X was this? MacOS X 10.3 has a working . MacOS X 10.2 has no wch

Re: [PATCH] fix quotearg when wchar.h is not used

Paolo Bonzini <[EMAIL PROTECTED]> writes: > * lib/quotearg.c [!HAVE_MBRTOWC]: Define mbstate_t to int. Thanks, I installed that.

[PATCH] fix quotearg when wchar.h is not used

While testing GNU sed's bootstrap mode (where it handcrafts a minimal config.h to work around system without a sed, or whose sed is not powerful enough to run configure), I found a bug in quotearg.c. If HAVE_WCHAR_H and HAVE_MBRTOWC are not set, various functions are #defined to work only on si

Re: [PATCH] Re: wctype.h and wchar.h inclusion

Derek Price <[EMAIL PROTECTED]> writes: > 2005-09-20 Yoann Vandoorselaere <[EMAIL PROTECTED]> > Derek Price <[EMAIL PROTECTED]> > > * m4/mbchar.m4 (gl_MBCHAR): Check for wchar.h & wctype.h, compiling > mbchar.c only when present. >

Re: [PATCH] Re: wctype.h and wchar.h inclusion

-20 Yoann Vandoorselaere <[EMAIL PROTECTED]> Derek Price <[EMAIL PROTECTED]> * m4/mbchar.m4 (gl_MBCHAR): Check for wchar.h & wctype.h, compiling mbchar.c only when present. * modules/mbchar (lib_SOURCES): Remove mbchar.c. Regards, Derek -- Derek

Re: [PATCH] Re: wctype.h and wchar.h inclusion

Derek Price <[EMAIL PROTECTED]> writes: > . Bruno doesn't like AC_LIBSOURCES so I doubt whether he'll accept that part of the patch. Surely you need only the AC_CHECK_HEADERS_ONCE and the AC_LIBOBJ part? _

Re: [PATCH] Re: wctype.h and wchar.h inclusion

Yoann Vandoorselaere wrote: >The mail you're pointing out is the patch I sent :-) >My question is rather whether it will be applied to the GnuLib CVS >version. > > Er, that's what I meant. :) I did apply and test it on several systems here, however, and it is working. :) Derek -- Derek R.

Re: [PATCH] Re: wctype.h and wchar.h inclusion

On Tue, 2005-09-20 at 09:43 -0400, Derek Price wrote: > Yoann Vandoorselaere wrote: > > >Bruno, is there any update concerning this issue ? > >GnuLib CVS has not being fixed, and this problem break the compile on a > >number of systems. > > > > > > I sent in a patch for this previously: >

Re: [PATCH] Re: wctype.h and wchar.h inclusion

Excuse me, I misspoke - the patch has been working on half a dozen systems for some weeks in nightly testing. I just finally got the other dozen or so systems up only a few days ago, but it's been compiling & testing ok there since they came up. Regards, Derek Derek Price wrote: >Yoann Vandoo

Re: [PATCH] Re: wctype.h and wchar.h inclusion

Yoann Vandoorselaere wrote: >Bruno, is there any update concerning this issue ? >GnuLib CVS has not being fixed, and this problem break the compile on a >number of systems. > > I sent in a patch for this previously: . This pa

Re: [PATCH] Re: wctype.h and wchar.h inclusion

e on > >>OpenBSD 3.7 due to the new dependencies of modules like strcase on > >>wctype.h and wchar.h headers. > >> > >> > > I've got a second system without the wchar.h, at least in the default > location: > > HP-UX hp291 B.11.00 U 9000

Re: [PATCH] Re: wctype.h and wchar.h inclusion

Yoann Vandoorselaere wrote: >On Thu, 2005-09-01 at 12:28 +0200, Yoann Vandoorselaere wrote: > > >>Hi, >> >>An OpenBSD Prelude user reported that GnuLib will fail to compile on >>OpenBSD 3.7 due to the new dependencies of modules like strcase on >>wctype.

[PATCH] Re: wctype.h and wchar.h inclusion

On Thu, 2005-09-01 at 12:28 +0200, Yoann Vandoorselaere wrote: > Hi, > > An OpenBSD Prelude user reported that GnuLib will fail to compile on > OpenBSD 3.7 due to the new dependencies of modules like strcase on > wctype.h and wchar.h headers. > > These headers are appare

wctype.h and wchar.h inclusion

Hi, An OpenBSD Prelude user reported that GnuLib will fail to compile on OpenBSD 3.7 due to the new dependencies of modules like strcase on wctype.h and wchar.h headers. These headers are apparently not available on OpenBSD base system. libutf8 provide these header, but they get installed in an