On Tue, Aug 17, 2010 at 2:44 PM, Kai Tietz <[email protected]> wrote: > 2010/8/17 Pete Batard <[email protected]>: >> 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 >> > > Ok, thanks for explaination. We will adjust this soon. Ozkan do you > want to take care here? >
I can. However I'd like to have a strict definition of what to do here: in winbase.h, I can change the Interlocked* api to __stdcall, but as I said that may cause problems with software compiled using older versions of mingw-w64. Are we OK with this? > Kai > > PS: For 64-bit this is a non-issue as x64 always uses a fastcall > convention and the stdcall/thiscall/cdecl are all in fact fastcall, > too. > s / __fastcall / __cdecl / ??? ------------------------------------------------------------------------------ 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
