2010/8/17 Ozkan Sezer <[email protected]>:
> 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?

I think we are here. As we provide in general all of those intrinsic
in our libmingex, the users shouldn't notice it. Those symbols aren't
treated here in general as imported.

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

No, fastcall is the default calling-convention. Register are used for
argument passing for the first 4 arguments.  But don't come to the
idea that they would be freely-exchangable, as compiler makes here
still differences about used calling-convention and will warning if
you are mixing things up here.

Kai

-- 
|  (\_/) This is Bunny. Copy and paste
| (='.'=) Bunny into your signature to help
| (")_(") him gain world domination

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

Reply via email to