2010/9/10 Ozkan Sezer <[email protected]>:
> On Fri, Sep 10, 2010 at 11:02 AM, Kai Tietz <[email protected]> wrote:
>> 2010/9/10 Ozkan Sezer <[email protected]>:
>>> 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
>>>>
>>>
>>
>> Hmm, always inline is bad too. As gcc allows in debugging build to
>> omit inlines, which allows debugging even of those.
>> I think it would be a better solution to provide an additional
>> intrinsic library for making gcc compatible to VS. I don't like to see
>
> That's a good idea. At least for driver builds like these especially
> if they are debug builds. However, we can also add _CRT_INLINE versions
> of them to wdm.h just like we do in winnt.h, any bad side effects you can
> think of? How does r/os deal with this?
>
>> this force-inline in headers as it has the tendency to hide stuff and
>> makes function pointer passing of those functions not correct working,
>> as each module gets an new version of this intrinsic.
>>
>> Kai
>>
>> --
>> | (\_/) This is Bunny. Copy and paste
>> | (='.'=) Bunny into your signature to help
>> | (")_(") him gain world domination
>>
>
> --
> Ozkan
>
Well, providing some of those __CRT_INLINE to ddk wouldn't hurt, but
well Amine can for sure enlight us here a bit how ros is handling
things here.
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
