2010/8/17 Kai Tietz <[email protected]>:
> 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
>
Pete,
could you provide us a list of the Interlock* API, which has stdcall
calling convention by our findings? Please just list names of those
functions and don't copy from VC's header-set. So we can adjust things
for win32 more easily without violating EULA.
Thanks,
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
