On Tue, Aug 17, 2010 at 2:52 PM, Kai Tietz <[email protected]> wrote:
> 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.
>
Hmm, thinking a little more, this need not be as much of an issue:
we have __cdecl versions in libmingwex, if we change into __stdcall
then old software can still succeed linking to libmingwex but new ones
will link to kernel32, so all we have to do is not change the local
implementations and keep them as __cdecl. Am I correct?
>>> 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.
>
OK
> Kai
>
> --
> | (\_/) This is Bunny. Copy and paste
> | (='.'=) Bunny into your signature to help
> | (")_(") him gain world domination
>
--
Ozkan
------------------------------------------------------------------------------
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
