2010/8/17 Ozkan Sezer <[email protected]>:
> 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?
No, we need to change local implementation, too. Otherwise call stack
gets broken. If we do this change, we have to change them all or none.
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
