On 2010.08.17 12:29, Ozkan Sezer wrote: >> Thank you Pete for noticing that. We are aware of this and we solved >> things here a bit different, but > > AFAIR, they aren't specifically marked as WINAPI in ms headers > (well, maybe their mistake?..)
Well, the thing is that the MSDN documentation has __cdecl [1], but looking at WinBase.h from a Visual Studio 2008 installation, there's a definite WINAPI qualifier on 32 bit. So there's some conflicting data there... I would think that if both MinGW32 and VS's WinBase.h use WINAPI on 32 bit, MinGW-w64 probably wants to follow suit >> maybe we could add here the stdcall >> decoration, too. Our Interlocked API is treated in our libmingwex and >> has here (as intrinsic) the __cdecl decoration. >> Therefore it shouldn't >> produce for you in general issues. >> Do you have here found issues while building? I'm afraid we have. When compiling libusb 1.0 in a multilib MinGW-w64 environment, we found that the resulting 32 bit library was unusable in MinGW32 [2]. Looking at it more closely, we found that the pure MinGW32 binary had '_interlockedexcha...@8' (=> __stdcall decoration) whereas the -m32 MinGW-w64 had '_InterlockedExchange' (=> __cdecl decoration). [3] Regards, /Pete [1] http://msdn.microsoft.com/en-us/library/ms683614%28VS.85%29.aspx [2] http://libusb.6.n5.nabble.com/Win-libusb-1-0-snapshots-no-longer-work-with-cross-compiling-of-libftdi-1-0-td2262878.html#a2262878 [3] http://libusb.6.n5.nabble.com/Win-libusb-1-0-snapshots-no-longer-work-with-cross-compiling-of-libftdi-1-0-tp2262878p2473397.html ------------------------------------------------------------------------------ This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev _______________________________________________ Mingw-w64-public mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
