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