On 09/18/13 10:57, Pedro Alves wrote: > On 09/17/2013 12:19 PM, Jacek Caban wrote: >> This is no-op for usual GCC targets, because we don't pass any string to >> CreateSemaphore anyway. However this trivial change will help >> mingw-w64's efforts to support WinRT, where only unicode variant is >> available. >> >> libgcc/Changelog: >> config/i386/gthr-win32.c: CreateSemaphoreW instead of CreateSemaphoreA. >> config/i386/gthr-win32.h: Likewise. >> > I'm a bit puzzled and curious about why you actually need this (and other > similar patches), since the Windows CE port manages without them, and there, > likewise only the W variants are available (for the whole Win32 API). > The w32api headers do things like: > > WINBASEAPI HANDLE WINAPI > CreateSemaphoreA(LPSECURITY_ATTRIBUTES,LONG,LONG,LPCSTR); > WINBASEAPI HANDLE WINAPI > CreateSemaphoreW(LPSECURITY_ATTRIBUTES,LONG,LONG,LPCWSTR); > > #ifdef UNICODE > #define CreateSemaphore CreateSemaphoreW > #else > #define CreateSemaphore CreateSemaphoreA > #endif > > AFAICS, the mingw-w64 headers do something equivalent. > > For Windows CE, UNICODE is always defined, so uses of CreateSemaphore > end up calling CreateSemaphoreW. Doesn't WinRT always define > UNICODE similarly? If not, shouldn't it?
Current mingw-w64 solution uses regular GCC build and adds a compatibility library for building for winrt target. This means that libgcc is not aware of winrt and is built for regular win32 target. Also, I think that being explicit about API variant we use is a good thing. UNICODE macro may be useful for stuff that has any reason to be changed by a switch, which is not the case here, IMO. Jacek
