On Fri, Sep 10, 2010 at 10:54 AM, Kai Tietz <[email protected]> wrote:
> 2010/9/10 Ozkan Sezer <[email protected]>:
>> On Fri, Sep 10, 2010 at 10:34 AM, Kai Tietz <[email protected]> wrote:
>>> 2010/9/10 Ozkan Sezer <[email protected]>:
>>>> On Fri, Sep 10, 2010 at 10:28 AM, Kai Tietz <[email protected]>
>>>> wrote:
>>>>> 2010/9/10 Teemu Nätkinniemi <[email protected]>:
>>>>>>
>>>>>>> libusb_driver.o:libusb_driver.c:(.text+0x6a9): undefined
>>>>>>> reference to `_Interloc
>>>>>>> kedIncrement'
>>>>>>> libusb_driver.o:libusb_driver.c:(.text+0x6d4): undefined
>>>>>>> reference to `_Interloc
>>>>>>> kedDecrement'
>>>>>>> libusb_driver.o:libusb_driver.c:(.text+0x70d): undefined
>>>>>>> reference to `_Interloc
>>>>>>> kedDecrement'
>>>>>>> transfer.o:transfer.c:(.text+0x149): undefined reference to
>>>>>>> `_InterlockedIncreme
>>>>>>> nt'
>>>>>>> transfer.o:transfer.c:(.text+0x19a): undefined reference to
>>>>>>> `_InterlockedDecreme
>>>>>>> nt'
>>>>>>> transfer.o:transfer.c:(.text+0x1cd): undefined reference to
>>>>>>> `_InterlockedDecreme
>>>>>>> nt'
>>>>>>> transfer.o:transfer.c:(.text+0x324): undefined reference to
>>>>>>> `_InterlockedDecreme
>>>>>>> nt'
>>>>>>> transfer.o:transfer.c:(.text+0x457): undefined reference to
>>>>>>> `_InterlockedExchang
>>>>>>> ePointer'
>>>>>>> transfer.o:transfer.c:(.text+0x4ed): undefined reference to
>>>>>>> `_InterlockedExchang
>>>>>>> ePointer'
>>>>>>> transfer.o:transfer.c:(.text+0x66d): undefined reference to
>>>>>>> `_InterlockedIncreme
>>>>>>> nt'
>>>>>>> transfer.o:transfer.c:(.text+0xe3f): undefined reference to
>>>>>>> `_InterlockedExchang
>>>>>>> ePointer'
>>>>>>> transfer.o:transfer.c:(.text+0xf76): undefined reference to
>>>>>>> `_InterlockedIncreme
>>>>>>> nt'
>>>>>>> collect2: ld returned 1 exit status
>>>>>>> make: *** [libusb0.sys] Error 1
>>>>>>
>>>>>> On 64-bit Windows those should be InterlockedIncrement64 and
>>>>>> InterlockedDecrement64.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>> On 64-bit are acutual no Interlocked...-API. It reflects always to
>>>>> _Interlocked..-API on x64. But why you get unresolved externals? We
>>>>> are providing those intrinsics in libminwex.a
>>>>
>>>> See wdm.h, they are probably expected to be exported from ntoskrnl.exe
>>>> I guess?
>>>>
>>>> As for libmingwex.a, they are linking with -nostdlib
>>>>
>>>>>
>>>>> Kai
>>>>>
>>>>
>>>> --
>>>> Ozkan
>>>>
>>>
>>> Well, to link without mingwex library cause here for sure issues as
>>> all intrinsics are missing. If they can't link to this library, then
>>> they need to provide at least a library which declares those
>>> intrinsics of VC, which are by obvious reasons not present in gcc.
>>> All this has for sure nothing to do with force-inline, as not all
>>> intrinsics are described in wdm.h headers as such kind of inlines.
>>
>>
>> wdm.h defines all of the Interlocked* as _Interlocked* for non-x86
>> so where is it supposed to retrieve them? Only as compiler builtins?
>>
>>
>>>
>>> Kai
>>>
>>>
>>> --
>>> | (\_/) This is Bunny. Copy and paste
>>> | (='.'=) Bunny into your signature to help
>>> | (")_(") him gain world domination
>>>
>>
>> --
>> Ozkan
>>
>
> Yes, you got it. And therefore we provide them in our libminwex.
>
Hrmph, I guess the only way here is to bite the bullet and
really add a -lmingwex after all other libs. However it would
have been really nice if we provided them as always_inlines
> Kai
>
> --
> | (\_/) This is Bunny. Copy and paste
> | (='.'=) Bunny into your signature to help
> | (")_(") him gain world domination
>
------------------------------------------------------------------------------
Automate Storage Tiering Simply
Optimize IT performance and efficiency through flexible, powerful,
automated storage tiering capabilities. View this brief to learn how
you can reduce costs and improve performance.
http://p.sf.net/sfu/dell-sfdev2dev
_______________________________________________
Mingw-w64-public mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
