The new option -municode incorrectly defines UNICODE. Instead, it should define _UNICODE. Jon_Y provided the following suggestion for a fix: Index: gcc/config/i386/mingw-w64.h =================================================================== --- gcc/config/i386/mingw-w64.h (revision 148266) +++ gcc/config/i386/mingw-w64.h (working copy) @@ -24,7 +24,7 @@ #undef CPP_SPEC #define CPP_SPEC "%{posix:-D_POSIX_SOURCE} %{mthreads:-D_MT} \ - %{municode:-DUNICODE}" + %{municode:-D_UNICODE}" #undef STARTFILE_SPEC #define STARTFILE_SPEC "%{shared|mdll:dllcrt2%O%s} \
Hi, to define UNICODE is absolutely correct. The define _UNICODE is fiction (but I agree it is in use). We can discuss about to define _UNICODE, too. But the UNICODE defines is for the w64 runtime the proper thing to define here. Cheers, Kai
Ok, it is no fiction, but a issue for tchar.h in CRT headers. See http://blogs.msdn.com/oldnewthing/archive/2004/02/12/71851.aspx so, we define UNICODE for PSDK, but _UNICODE is user defined AFAIU. But possibly we could add the _UNICODE define for CRT's sake, too. Kai
As further research has shown, is the definition of _UNICODE a thing the user has to take care. The _UNICODE define is used in tchar.h and documentation for this can be found on msdn.
Subject: Re: GCC defines UNICODE instead of _UNICODE for -municode On Mon, 8 Jun 2009, ktietz at gcc dot gnu dot org wrote: > to define UNICODE is absolutely correct. The define _UNICODE is fiction (but I UNICODE is in the user's namespace; it should not be predefined if flag_iso (if you have to use specs rather than hooks, you need %{!ansi:%{!std=i*:%{!std=c*:-DUNICODE}}} to detect the various conformance options). We should not add to the instances of bug 545 that are still present. If the MinGW headers use a macro in the user's namespace as a feature test macro of some sort, they are buggy and should be fixed (with fixincludes if necessary for existing installations).
(In reply to comment #4) > Subject: Re: GCC defines UNICODE instead of _UNICODE > for -municode > > UNICODE is in the user's namespace; it should not be predefined if > flag_iso (if you have to use specs rather than hooks, you need > %{!ansi:%{!std=i*:%{!std=c*:-DUNICODE}}} to detect the various conformance > options). We should not add to the instances of bug 545 that are still > present. If the MinGW headers use a macro in the user's namespace as a > feature test macro of some sort, they are buggy and should be fixed (with > fixincludes if necessary for existing installations). > It is right that _UNICODE and UNICODE are in user name space defined and are controlling which API (wide/or ascii) has to be used. UNICODE is used in windows headers itself (see msdn for documentation). _UNICODE is used in CRT (and inspecial in tchar.h header) only. (This is also documented in msdn). I agree, that these two different macro names are a bit annoying, but for sure they are platform specific stuff and are for sure absolutely unrelated to ISO. Therefore to introduce a relationship to ISO defines is contradictive and wrong. Those macros are controling behaviour of runtime. By the windows specific switch -municode the windows runtime is controlled. Cheers, Kai