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