>- Copy libusb.h, from include/libusb-1.0/ to your default include
> directory,
> and copy the MinGW32/ or MinGW64/ .a files to your default library
> directory.
> Or, if you don't want to use the default locations, make sure that you
> feed
> the relevant -I and -L options to
Peter Balazovic writes:
> Dears,
>
> I'm looking for "simple" advice on use of libusb within mingw-w64 ?
>
> I use mingw-w64 installed as \mingw-w64\i686-5.3.0-posix-dwarf-rt_v4-rev0\
>
> I have downloaded libusb from
> https://sourceforge.net/projects/libusb/files/libusb-1.0/libusb-1.0.20
>
> On
Dears,
I'm looking for "simple" advice on use of libusb within mingw-w64 ?
I use mingw-w64 installed as \mingw-w64\i686-5.3.0-posix-dwarf-rt_v4-rev0\
I have downloaded libusb from
https://sourceforge.net/projects/libusb/files/libusb-1.0/libusb-1.0.20
On libusb installation the README.txt file s
On Mon, Sep 20, 2010 at 9:57 PM, Ozkan Sezer wrote:
> On Mon, Sep 20, 2010 at 4:03 PM, Xiaofan Chen wrote:
>> In this case, MinGW is actually following MS side, and not MinGW-w64,
>> Even Kai Tietz admits that MinGW-w64 usb.h belongs to DDK. It is just
>> because of the convenience (to support w
On Mon, Sep 20, 2010 at 4:03 PM, Xiaofan Chen wrote:
> On Mon, Sep 20, 2010 at 8:50 PM, Earnie wrote:
>> Ozkan Sezer wrote:
>>> Mingw has not been updating their ddk for years and certainly they
>>> don't reflect the changes is directory structure from the MS side:
>>> mingw does not define the a
2010/9/20 Earnie :
> Ozkan Sezer wrote:
>> On Sun, Sep 19, 2010 at 2:03 PM, Xiaofan Chen
>> wrote:
>>> On Sun, Sep 19, 2010 at 6:44 PM, Ozkan Sezer
>>> wrote:
> However, MinGW does not break existing software and puts those
> files inside include\ddk sub-directory. Why not MinGW-w64?
On Mon, Sep 20, 2010 at 8:50 PM, Earnie wrote:
> Ozkan Sezer wrote:
>> Mingw has not been updating their ddk for years and certainly they
>> don't reflect the changes is directory structure from the MS side:
>> mingw does not define the api or directory structure, ms does.
>>
>> I think we put eve
Ozkan Sezer wrote:
> On Sun, Sep 19, 2010 at 2:03 PM, Xiaofan Chen
> wrote:
>> On Sun, Sep 19, 2010 at 6:44 PM, Ozkan Sezer
>> wrote:
However, MinGW does not break existing software and puts those
files inside include\ddk sub-directory. Why not MinGW-w64?
>>>
>>> What will happen to oth
On Mon, Sep 20, 2010 at 1:28 AM, Kai Tietz wrote:
> The usb.h header is here in our platform headers as we need it for the
> case that no ddk is installed and somebody wants to use winusb.h
> header.
OK this is a very good reason. WinUSB is useful. And indeed using
WinUSB will need to have access
On Sun, Sep 19, 2010 at 8:28 PM, Kai Tietz wrote:
> 2010/9/19 Ozkan Sezer :
>> On Sun, Sep 19, 2010 at 2:03 PM, Xiaofan Chen wrote:
>>> On Sun, Sep 19, 2010 at 6:44 PM, Ozkan Sezer wrote:
> However, MinGW does not break existing software and puts
> those files inside include\ddk sub-dire
2010/9/19 Ozkan Sezer :
> On Sun, Sep 19, 2010 at 2:03 PM, Xiaofan Chen wrote:
>> On Sun, Sep 19, 2010 at 6:44 PM, Ozkan Sezer wrote:
However, MinGW does not break existing software and puts
those files inside include\ddk sub-directory. Why not
MinGW-w64?
>>>
>>> What will happen t
On Sun, Sep 19, 2010 at 2:03 PM, Xiaofan Chen wrote:
> On Sun, Sep 19, 2010 at 6:44 PM, Ozkan Sezer wrote:
>>> However, MinGW does not break existing software and puts
>>> those files inside include\ddk sub-directory. Why not
>>> MinGW-w64?
>>
>> What will happen to other software that expect usb
On Sun, Sep 19, 2010 at 6:44 PM, Ozkan Sezer wrote:
>> However, MinGW does not break existing software and puts
>> those files inside include\ddk sub-directory. Why not
>> MinGW-w64?
>
> What will happen to other software that expect usb.h
> out of ddk subdirectory, then?
Please name one. And you
On Sun, Sep 19, 2010 at 1:40 PM, Xiaofan Chen wrote:
> On Sun, Sep 19, 2010 at 6:18 PM, Ozkan Sezer wrote:
>
>>> Yes WDK has several directories of headers. Apparently
>>> "api" sub-directory is more than the "SDK counterpart"
>>> since it includes many files not included in the SDK.
>>>
>>
>> Th
On Sun, Sep 19, 2010 at 6:18 PM, Ozkan Sezer wrote:
>> Yes WDK has several directories of headers. Apparently
>> "api" sub-directory is more than the "SDK counterpart"
>> since it includes many files not included in the SDK.
>>
>
> The point is, the "api" subdirectory also contains windows.h,
> e
On Sun, Sep 19, 2010 at 1:11 PM, Xiaofan Chen wrote:
> On Sun, Sep 19, 2010 at 4:54 PM, Ozkan Sezer wrote:
I said that assuming mingw-w64 was following MS. Ozkan where
does usb.h live in MS's SDK stack?
>>>
>>
>> Dongsheng Song is correct that WDK has it in the "api"
>> directory which
On Sun, Sep 19, 2010 at 4:54 PM, Ozkan Sezer wrote:
>>> I said that assuming mingw-w64 was following MS. Ozkan where
>>> does usb.h live in MS's SDK stack?
>>
>
> Dongsheng Song is correct that WDK has it in the "api"
> directory which is the sdk counterpart in their standalone
> ddk package. (WD
On Sun, Sep 19, 2010 at 6:34 AM, Xiaofan Chen wrote:
> On Sun, Sep 19, 2010 at 9:54 AM, JonY wrote:
>> All the headers provided under our include directory are
>> already part of sdk, therefore I don't know how a separation
>> can be possible.
>>
>> Admins?
>>
> Person
On Sun, Sep 19, 2010 at 9:54 AM, JonY wrote:
> All the headers provided under our include directory are
> already part of sdk, therefore I don't know how a separation
> can be possible.
>
> Admins?
>
Personally, I think deviating from MS is a bad idea. If ms puts it in
On 9/19/2010 09:57, Xiaofan Chen wrote:
> On Sun, Sep 19, 2010 at 9:44 AM, Xiaofan Chen wrote:
>> On Sun, Sep 19, 2010 at 9:03 AM, JonY wrote:
All the headers provided under our include directory are
already part of sdk, therefore I don't know how a separation
can be possible.
On Sun, Sep 19, 2010 at 10:04 AM, Dongsheng Song
wrote:
> On Sun, Sep 19, 2010 at 07:50, Ozkan Sezer wrote:
>>
>> AFAIK, usb.h is out of ddk because it is part of ms platform sdk,
>> therefore, it _needs_ to be out of a ddk subdirectory for proper
>> compatibility.
>
> No, usb.h is in MS WDK 7.1
On Sun, Sep 19, 2010 at 07:50, Ozkan Sezer wrote:
>
> AFAIK, usb.h is out of ddk because it is part of ms platform sdk,
> therefore, it _needs_ to be out of a ddk subdirectory for proper
> compatibility.
>
No, usb.h is in MS WDK 7.1 now:
C:\opt\WinDDK\7.1\inc\api>dir *usb*
驱动器 C 中的卷没有标签。
卷的序列
On Sun, Sep 19, 2010 at 9:44 AM, Xiaofan Chen wrote:
> On Sun, Sep 19, 2010 at 9:03 AM, JonY wrote:
>>> All the headers provided under our include directory are
>>> already part of sdk, therefore I don't know how a separation
>>> can be possible.
>>>
>>> Admins?
>>>
>> Personally, I think deviati
On Sun, Sep 19, 2010 at 9:03 AM, JonY wrote:
>> All the headers provided under our include directory are
>> already part of sdk, therefore I don't know how a separation
>> can be possible.
>>
>> Admins?
>>
> Personally, I think deviating from MS is a bad idea. If ms puts it in the
> normal psdk, s
On 9/19/2010 08:00, Ozkan Sezer wrote:
> On Sun, Sep 19, 2010 at 2:56 AM, Xiaofan Chen wrote:
>> On Sun, Sep 19, 2010 at 7:50 AM, Ozkan Sezer wrote:
>>> On Sun, Sep 19, 2010 at 2:38 AM, Xiaofan Chen wrote:
I think the MinGW-w64 newly included usb.h will break
many existing software whi
On Sun, Sep 19, 2010 at 2:56 AM, Xiaofan Chen wrote:
> On Sun, Sep 19, 2010 at 7:50 AM, Ozkan Sezer wrote:
>> On Sun, Sep 19, 2010 at 2:38 AM, Xiaofan Chen wrote:
>>> I think the MinGW-w64 newly included usb.h will break
>>> many existing software which uses libusb-win32. For
>>> example, libftd
On Sun, Sep 19, 2010 at 7:50 AM, Ozkan Sezer wrote:
> On Sun, Sep 19, 2010 at 2:38 AM, Xiaofan Chen wrote:
>> I think the MinGW-w64 newly included usb.h will break
>> many existing software which uses libusb-win32. For
>> example, libftdi's header is called ftdi.h which includes .
>> libusb and l
On Sun, Sep 19, 2010 at 2:38 AM, Xiaofan Chen wrote:
> On Sun, Sep 12, 2010 at 5:34 PM, Xiaofan Chen wrote:
>> On Thu, Sep 9, 2010 at 3:53 AM, Ozkan Sezer wrote:
>>> 2. the name of your src/usb.h is, well, usb.h, and it conflicts, ie.
>>> searched before the system provided usb.h. Therefore, it
On Sun, Sep 12, 2010 at 5:34 PM, Xiaofan Chen wrote:
> On Thu, Sep 9, 2010 at 3:53 AM, Ozkan Sezer wrote:
>> 2. the name of your src/usb.h is, well, usb.h, and it conflicts, ie.
>> searched before the system provided usb.h. Therefore, it must be
>> renamed to something else. For my own tests, I
On Sun, Sep 12, 2010 at 5:26 PM, Ruben Van Boxem
wrote:
>> building. What is the easy way to differentiate MinGW-w64
>> 32bit compiler and MinGW.org 32bit compiler? Then we
>> can add ifdefs in the source codes to cater for both in the
>> future.
>>
>> The current codes are set up in a way to supp
>
> building. What is the easy way to differentiate MinGW-w64
> 32bit compiler and MinGW.org 32bit compiler? Then we
> can add ifdefs in the source codes to cater for both in the
> future.
>
> The current codes are set up in a way to support MinGW.org
> for 32bit build and MinGW-w64 64bit for 64bit
On Sun, Sep 12, 2010 at 11:52 AM, Xiaofan Chen wrote:
> On Sun, Sep 12, 2010 at 11:38 AM, Xiaofan Chen wrote:
>> On Sat, Sep 11, 2010 at 9:36 PM, Ozkan Sezer wrote:
>>> So far, good news from both of the x86 and x64 fronts. Will wait
>>> for the news about performance.
>>
>> I tried to use the
On 9/12/2010 11:38, Xiaofan Chen wrote:
> On Sat, Sep 11, 2010 at 9:36 PM, Ozkan Sezer wrote:
>> So far, good news from both of the x86 and x64 fronts. Will wait
>> for the news about performance.
>
> I tried to use the 32bit driver under Windows 7 32bit and it
> seems to work fine. The simple te
On Sun, Sep 12, 2010 at 11:52 AM, Xiaofan Chen wrote:
>> I tried to use the 32bit driver under Windows 7 32bit and it
>> seems to work fine. The simple test programs (like testlibusb
>> and testlibusb-win) run fine.
>
> The main problem I found with the 64bit applications under
> Windows 7 x64 is
On Sun, Sep 12, 2010 at 11:38 AM, Xiaofan Chen wrote:
> On Sat, Sep 11, 2010 at 9:36 PM, Ozkan Sezer wrote:
>> So far, good news from both of the x86 and x64 fronts. Will wait
>> for the news about performance.
>
> I tried to use the 32bit driver under Windows 7 32bit and it
> seems to work fine
On Sat, Sep 11, 2010 at 9:36 PM, Ozkan Sezer wrote:
> So far, good news from both of the x86 and x64 fronts. Will wait
> for the news about performance.
I tried to use the 32bit driver under Windows 7 32bit and it
seems to work fine. The simple test programs (like testlibusb
and testlibusb-win)
On Sat, Sep 11, 2010 at 4:39 PM, Kai Tietz wrote:
> 2010/9/11 Ozkan Sezer :
>> On Sat, Sep 11, 2010 at 4:15 PM, Xiaofan Chen wrote:
>>> On Sat, Sep 11, 2010 at 9:10 PM, Xiaofan Chen wrote:
On Sat, Sep 11, 2010 at 9:04 PM, Ozkan Sezer wrote:
> OK, reading wdm.h more carefully, the FASTC
2010/9/11 Ozkan Sezer :
> On Sat, Sep 11, 2010 at 4:15 PM, Xiaofan Chen wrote:
>> On Sat, Sep 11, 2010 at 9:10 PM, Xiaofan Chen wrote:
>>> On Sat, Sep 11, 2010 at 9:04 PM, Ozkan Sezer wrote:
OK, reading wdm.h more carefully, the FASTCALL declarations are
protected by an #ifdef NO_INTER
On Sat, Sep 11, 2010 at 4:15 PM, Xiaofan Chen wrote:
> On Sat, Sep 11, 2010 at 9:10 PM, Xiaofan Chen wrote:
>> On Sat, Sep 11, 2010 at 9:04 PM, Ozkan Sezer wrote:
>>> OK, reading wdm.h more carefully, the FASTCALL declarations are
>>> protected by an #ifdef NO_INTERLOCKED_INTRINSICS guard: For
On Sat, Sep 11, 2010 at 9:10 PM, Xiaofan Chen wrote:
> On Sat, Sep 11, 2010 at 9:04 PM, Ozkan Sezer wrote:
>> OK, reading wdm.h more carefully, the FASTCALL declarations are
>> protected by an #ifdef NO_INTERLOCKED_INTRINSICS guard: For x86,
>> can you please recompile by adding -DNO_INTERLOCKE
On Sat, Sep 11, 2010 at 9:04 PM, Ozkan Sezer wrote:
> OK, reading wdm.h more carefully, the FASTCALL declarations are
> protected by an #ifdef NO_INTERLOCKED_INTRINSICS guard: For x86,
> can you please recompile by adding -DNO_INTERLOCKED_INTRINSICS
> and see if it links and works?
Yes this wor
On Sat, Sep 11, 2010 at 3:46 PM, Xiaofan Chen wrote:
> On Sat, Sep 11, 2010 at 8:43 PM, Ozkan Sezer wrote:
>>> set_configuration.o:set_configuration.c:(.text+0x1c8): undefined reference
>>> to `U
>>> sbd_createconfigurationreques...@8'
>>
>> For this particular one, I think you can use your old
On Sat, Sep 11, 2010 at 3:50 PM, Pete Batard wrote:
> On 2010.09.11 13:46, Kai Tietz wrote:
>> 2010/9/11 Ozkan Sezer:
>>> On Sat, Sep 11, 2010 at 3:37 PM, Xiaofan Chen wrote:
On Sat, Sep 11, 2010 at 8:31 PM, Ozkan Sezer wrote:
> You need the @8 _and_ the leading underscore for x86
>
On 2010.09.11 13:46, Kai Tietz wrote:
> 2010/9/11 Ozkan Sezer:
>> On Sat, Sep 11, 2010 at 3:37 PM, Xiaofan Chen wrote:
>>> On Sat, Sep 11, 2010 at 8:31 PM, Ozkan Sezer wrote:
You need the @8 _and_ the leading underscore for x86
So you need adjusting your Makefile and libusb0_drv.def
>>>
On Sat, Sep 11, 2010 at 3:46 PM, Kai Tietz wrote:
> 2010/9/11 Ozkan Sezer :
>> On Sat, Sep 11, 2010 at 3:37 PM, Xiaofan Chen wrote:
>>> On Sat, Sep 11, 2010 at 8:31 PM, Ozkan Sezer wrote:
You need the @8 _and_ the leading underscore for x86
So you need adjusting your Makefile and libus
On Sat, Sep 11, 2010 at 8:43 PM, Ozkan Sezer wrote:
>> set_configuration.o:set_configuration.c:(.text+0x1c8): undefined reference
>> to `U
>> sbd_createconfigurationreques...@8'
>
> For this particular one, I think you can use your old usbd.def file but, ...
Yes you are right. I just reverted to
2010/9/11 Ozkan Sezer :
> On Sat, Sep 11, 2010 at 3:37 PM, Xiaofan Chen wrote:
>> On Sat, Sep 11, 2010 at 8:31 PM, Ozkan Sezer wrote:
>>> You need the @8 _and_ the leading underscore for x86
>>> So you need adjusting your Makefile and libusb0_drv.def
>>> for two different builds.
>>
>> Thanks. I
On Sat, Sep 11, 2010 at 3:37 PM, Xiaofan Chen wrote:
> On Sat, Sep 11, 2010 at 8:31 PM, Ozkan Sezer wrote:
>> You need the @8 _and_ the leading underscore for x86
>> So you need adjusting your Makefile and libusb0_drv.def
>> for two different builds.
>
> Thanks. I fixed the Makefile and now I hav
On Sat, Sep 11, 2010 at 8:31 PM, Ozkan Sezer wrote:
> You need the @8 _and_ the leading underscore for x86
> So you need adjusting your Makefile and libusb0_drv.def
> for two different builds.
Thanks. I fixed the Makefile and now I have the following.
windres -I./src --target=pe-i386 ./src/dri
On Sat, Sep 11, 2010 at 3:20 PM, Xiaofan Chen wrote:
> On Sat, Sep 11, 2010 at 4:00 PM, Ozkan Sezer wrote:
>> Oki dokie, msg received. Lets try with this new one (changed the
>> static inline to extern __inline __attribute__((__gnu_inline__))
>
> BTW, could you provide similar file for x86? Thank
On Sat, Sep 11, 2010 at 4:00 PM, Ozkan Sezer wrote:
> Oki dokie, msg received. Lets try with this new one (changed the
> static inline to extern __inline __attribute__((__gnu_inline__))
BTW, could you provide similar file for x86? Thanks.
I changed the Makefile to build the 32bit driver with TDM
On Sat, Sep 11, 2010 at 8:01 PM, Kai Tietz wrote:
> Another thing about performance issues here (those inlines will help
> for sure a bit). What optimizations you are using for gcc?
>
I am using -O2.
Actually the WDK build is with debug option on, not the release build.
But I need to carry out s
2010/9/11 Xiaofan Chen :
> On Sat, Sep 11, 2010 at 4:00 PM, Ozkan Sezer wrote:
>>>Try a recompile with this and see
>>>- if the likage succeds
>>>- if you still have a performance issue by comparison to the msvc builds
>>
>> Oki dokie, msg received. Lets try with this new one (changed the
>> stati
On Sat, Sep 11, 2010 at 4:00 PM, Ozkan Sezer wrote:
>>Try a recompile with this and see
>>- if the likage succeds
>>- if you still have a performance issue by comparison to the msvc builds
>
> Oki dokie, msg received. Lets try with this new one (changed the
> static inline to extern __inline __att
On Sat, Sep 11, 2010 at 10:52 AM, Xiaofan Chen wrote:
> On Sat, Sep 11, 2010 at 3:38 PM, Ozkan Sezer wrote:
>>> It will still producing the following linking errors. Take note the
>>> underscore.
>>>
>>
>> Well, that should be the easy part to fix, see the new version attached
>> (was my fault f
On Sat, Sep 11, 2010 at 3:38 PM, Ozkan Sezer wrote:
>> It will still producing the following linking errors. Take note the
>> underscore.
>>
>
> Well, that should be the easy part to fix, see the new version attached
> (was my fault forgetting to add the underscores)
>
> Try a recompile with this
On Sat, Sep 11, 2010 at 10:34 AM, Xiaofan Chen wrote:
> On Sat, Sep 11, 2010 at 2:44 PM, Ozkan Sezer wrote:
>>> I will carry out more tests but it seems there are performance issues
>>> when using the MinGW-w64 build of libusb0.sys compared to the WDK
>>> build, especially when using as a filter
On Sat, Sep 11, 2010 at 3:34 PM, Xiaofan Chen wrote:
> On Sat, Sep 11, 2010 at 2:44 PM, Ozkan Sezer wrote:
>> Try adding the attached inlines to your wdm.h (I think around line 242 just
>> before the #endif /* defined(__GNUC__) */ ) and remove the -lmingwex
>> from your makefile. These are the I
On Sat, Sep 11, 2010 at 2:44 PM, Ozkan Sezer wrote:
>> I will carry out more tests but it seems there are performance issues
>> when using the MinGW-w64 build of libusb0.sys compared to the WDK
>> build, especially when using as a filter driver. I am wondering if this can
>> be the consequences of
On Sat, Sep 11, 2010 at 6:56 AM, Xiaofan Chen wrote:
> On Fri, Sep 10, 2010 at 4:37 PM, Kai Tietz wrote:
> 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_
On Fri, Sep 10, 2010 at 4:37 PM, Kai Tietz wrote:
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
>>> Hmm, always inline is bad too. As gcc
Greetings,
I'm playing catch up here so apologies if this has already been covered,
but..
There is an @8 on DriverEntry in the libusb0_drv.def file. I'm not exactly
sure how gcc handles this on a 64bit machine. Could this be causing a
problem?
Xiao is right, the support here is great!
Regar
On 9/10/2010 22:54, Xiaofan Chen wrote:
> On Fri, Sep 10, 2010 at 10:16 PM, Travis wrote:
>> I'm playing catch up here so apologies if this has already been covered,
>> but..
>>
>> There is an @8 on DriverEntry in the libusb0_drv.def file. I'm not exactly
>> sure how gcc handles this on a 64bit m
On Fri, Sep 10, 2010 at 10:16 PM, Travis wrote:
> I'm playing catch up here so apologies if this has already been covered,
> but..
>
> There is an @8 on DriverEntry in the libusb0_drv.def file. I'm not exactly
> sure how gcc handles this on a 64bit machine. Could this be causing a
> problem?
As
On Fri, Sep 10, 2010 at 5:59 PM, Xiaofan Chen wrote:
>> Not sure here, it could be here undefined references DLLs, or
>> unavailable API. You can check imports here by using objdump -x
>> to see more details.
>
> I will check that.
Even though the issue seems to be solved, I still want to provid
On Fri, Sep 10, 2010 at 5:21 PM, Xiaofan Chen wrote:
> On Fri, Sep 10, 2010 at 6:40 PM, Ozkan Sezer wrote:
>> On Fri, Sep 10, 2010 at 1:34 PM, Xiaofan Chen wrote:
>>> On Fri, Sep 10, 2010 at 6:31 PM, Ozkan Sezer wrote:
>>>
Speaking of linkage to usbd.sys, where did you get libusbd.a for li
On Fri, Sep 10, 2010 at 6:40 PM, Ozkan Sezer wrote:
> On Fri, Sep 10, 2010 at 1:34 PM, Xiaofan Chen wrote:
>> On Fri, Sep 10, 2010 at 6:31 PM, Ozkan Sezer wrote:
>>
>>> Speaking of linkage to usbd.sys, where did you get libusbd.a for linking
>>> to it? AFAICS, we don't provide it (shame on us.)
On Fri, Sep 10, 2010 at 1:34 PM, Xiaofan Chen wrote:
> On Fri, Sep 10, 2010 at 6:31 PM, Ozkan Sezer wrote:
>
>> Speaking of linkage to usbd.sys, where did you get libusbd.a for linking
>> to it? AFAICS, we don't provide it (shame on us.) Your libusb0.sys looks
>> for a _USBD_CreateConfigurationR
On Fri, Sep 10, 2010 at 6:31 PM, Ozkan Sezer wrote:
> Speaking of linkage to usbd.sys, where did you get libusbd.a for linking
> to it? AFAICS, we don't provide it (shame on us.) Your libusb0.sys looks
> for a _USBD_CreateConfigurationRequestEx, notice the leading underscore,
> so can this be th
On Fri, Sep 10, 2010 at 1:18 PM, Ozkan Sezer wrote:
> On Fri, Sep 10, 2010 at 1:11 PM, Kai Tietz wrote:
>> 2010/9/10 Ozkan Sezer :
>>> On Fri, Sep 10, 2010 at 12:59 PM, Xiaofan Chen wrote:
On Fri, Sep 10, 2010 at 5:43 PM, Kai Tietz wrote:
>> Unfortunately it does not work under Wi
Thanks for all the suggestions. I will try them and report back.
On our side, we need quite a bit of cleaning on supporting MinGW-w64
as well, not only for the driver building, but also for other parts
(dll/filter/test/testwin target) and fix the Makefile for infwizard
(mixed 32bit/64bit build iss
On Fri, Sep 10, 2010 at 1:11 PM, Kai Tietz wrote:
> 2010/9/10 Ozkan Sezer :
>> On Fri, Sep 10, 2010 at 12:59 PM, Xiaofan Chen wrote:
>>> On Fri, Sep 10, 2010 at 5:43 PM, Kai Tietz wrote:
>>>
> Unfortunately it does not work under Windows 7 x64.
>
> I got the following error.
> "W
2010/9/10 Ozkan Sezer :
> On Fri, Sep 10, 2010 at 12:59 PM, Xiaofan Chen wrote:
>> On Fri, Sep 10, 2010 at 5:43 PM, Kai Tietz wrote:
>>
Unfortunately it does not work under Windows 7 x64.
I got the following error.
"Windows cannot load the device driver for this hardware.
On Fri, Sep 10, 2010 at 12:59 PM, Xiaofan Chen wrote:
> On Fri, Sep 10, 2010 at 5:43 PM, Kai Tietz wrote:
>
>>> Unfortunately it does not work under Windows 7 x64.
>>>
>>> I got the following error.
>>> "Windows cannot load the device driver for this hardware.
>>> The driver may be corrupted or m
On Fri, Sep 10, 2010 at 5:43 PM, Kai Tietz wrote:
>> Unfortunately it does not work under Windows 7 x64.
>>
>> I got the following error.
>> "Windows cannot load the device driver for this hardware.
>> The driver may be corrupted or missing. (Code 39)"
>>
>> I will update later with more informat
2010/9/10 Xiaofan Chen :
> On Fri, Sep 10, 2010 at 4:27 PM, Xiaofan Chen wrote:
>
>>> Thanks for the explanations. Now I need to test this MinGW-w64
>>> build driver. I will come back if I encounter problems.
>>
>> The modified source and binaries are archived here.
>> http://code.google.com/p/pic
On Fri, Sep 10, 2010 at 4:27 PM, Xiaofan Chen wrote:
>> Thanks for the explanations. Now I need to test this MinGW-w64
>> build driver. I will come back if I encounter problems.
>
> The modified source and binaries are archived here.
> http://code.google.com/p/picusb/downloads/list
> (libusb-win
2010/9/10 Ozkan Sezer :
> On Fri, Sep 10, 2010 at 11:02 AM, Kai Tietz wrote:
>> 2010/9/10 Ozkan Sezer :
>>> On Fri, Sep 10, 2010 at 10:54 AM, Kai Tietz wrote:
2010/9/10 Ozkan Sezer :
> On Fri, Sep 10, 2010 at 10:34 AM, Kai Tietz
> wrote:
>> 2010/9/10 Ozkan Sezer :
>>> On Fr
On Fri, Sep 10, 2010 at 11:02 AM, Kai Tietz wrote:
> 2010/9/10 Ozkan Sezer :
>> On Fri, Sep 10, 2010 at 10:54 AM, Kai Tietz wrote:
>>> 2010/9/10 Ozkan Sezer :
On Fri, Sep 10, 2010 at 10:34 AM, Kai Tietz
wrote:
> 2010/9/10 Ozkan Sezer :
>> On Fri, Sep 10, 2010 at 10:28 AM, Kai
On Fri, Sep 10, 2010 at 4:21 PM, Xiaofan Chen wrote:
> On Fri, Sep 10, 2010 at 4:18 PM, Kai Tietz wrote:
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_inl
On Fri, Sep 10, 2010 at 4:18 PM, Kai Tietz wrote:
>>> 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
>>
>> Yes changing the Makefile to link to libmingwex
2010/9/10 Xiaofan Chen :
> On Fri, Sep 10, 2010 at 3:59 PM, Ozkan Sezer wrote:
>
> 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
>
On Fri, Sep 10, 2010 at 11:15 AM, Xiaofan Chen wrote:
> On Fri, Sep 10, 2010 at 3:59 PM, Ozkan Sezer wrote:
>
> 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
On Fri, Sep 10, 2010 at 3:59 PM, Ozkan Sezer wrote:
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
2010/9/10 Ozkan Sezer :
> On Fri, Sep 10, 2010 at 10:54 AM, Kai Tietz wrote:
>> 2010/9/10 Ozkan Sezer :
>>> On Fri, Sep 10, 2010 at 10:34 AM, Kai Tietz wrote:
2010/9/10 Ozkan Sezer :
> On Fri, Sep 10, 2010 at 10:28 AM, Kai Tietz
> wrote:
>> 2010/9/10 Teemu Nätkinniemi :
>>>
On Fri, Sep 10, 2010 at 10:54 AM, Kai Tietz wrote:
> 2010/9/10 Ozkan Sezer :
>> On Fri, Sep 10, 2010 at 10:34 AM, Kai Tietz wrote:
>>> 2010/9/10 Ozkan Sezer :
On Fri, Sep 10, 2010 at 10:28 AM, Kai Tietz
wrote:
> 2010/9/10 Teemu Nätkinniemi :
>>
>>> libusb_driver.o:libusb_d
2010/9/10 Ozkan Sezer :
> On Fri, Sep 10, 2010 at 10:34 AM, Kai Tietz wrote:
>> 2010/9/10 Ozkan Sezer :
>>> On Fri, Sep 10, 2010 at 10:28 AM, Kai Tietz wrote:
2010/9/10 Teemu Nätkinniemi :
>
>> libusb_driver.o:libusb_driver.c:(.text+0x6a9): undefined
>> reference to `_Interloc
>>
On Fri, Sep 10, 2010 at 10:34 AM, Kai Tietz wrote:
> 2010/9/10 Ozkan Sezer :
>> On Fri, Sep 10, 2010 at 10:28 AM, Kai Tietz wrote:
>>> 2010/9/10 Teemu Nätkinniemi :
> libusb_driver.o:libusb_driver.c:(.text+0x6a9): undefined
> reference to `_Interloc
> kedIncrement'
> libusb_d
On Fri, Sep 10, 2010 at 3:34 PM, Kai Tietz wrote:
>>> 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 expor
2010/9/10 Xiaofan Chen :
> On Fri, Sep 10, 2010 at 3:29 PM, Ozkan Sezer wrote:
gcc -o libusb0.sys abort_endpoint.o claim_interface.o clear_feature.o
dispatch.o
get_configuration.o get_descriptor.o get_interface.o get_status.o ioctl.o
libus
b_driver.o pnp.o release_inter
On Fri, Sep 10, 2010 at 3:29 PM, Ozkan Sezer wrote:
>>> gcc -o libusb0.sys abort_endpoint.o claim_interface.o clear_feature.o
>>> dispatch.o
>>> get_configuration.o get_descriptor.o get_interface.o get_status.o ioctl.o
>>> libus
>>> b_driver.o pnp.o release_interface.o reset_device.o reset_endp
2010/9/10 Ozkan Sezer :
> On Fri, Sep 10, 2010 at 10:28 AM, Kai Tietz wrote:
>> 2010/9/10 Teemu Nätkinniemi :
>>>
libusb_driver.o:libusb_driver.c:(.text+0x6a9): undefined
reference to `_Interloc
kedIncrement'
libusb_driver.o:libusb_driver.c:(.text+0x6d4): undefined
referen
On Fri, Sep 10, 2010 at 10:28 AM, Kai Tietz wrote:
> 2010/9/10 Teemu Nätkinniemi :
>>
>>> 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
On Fri, Sep 10, 2010 at 9:52 AM, Ozkan Sezer wrote:
> On Fri, Sep 10, 2010 at 9:47 AM, Xiaofan Chen wrote:
>> On Fri, Sep 10, 2010 at 2:07 PM, Ozkan Sezer wrote:
>>
>>> Well, src/driver/usbdlib_gcc.h at line around 23, I added :
>>>
>>> #if !defined(DDKAPI)
>>> #define DDKAPI NTAPI
>>> #endif
>>
2010/9/10 Teemu Nätkinniemi :
>
>> 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
> 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
> kedDecrem
On Fri, Sep 10, 2010 at 9:47 AM, Xiaofan Chen wrote:
> On Fri, Sep 10, 2010 at 2:07 PM, Ozkan Sezer wrote:
>
>> Well, src/driver/usbdlib_gcc.h at line around 23, I added :
>>
>> #if !defined(DDKAPI)
>> #define DDKAPI NTAPI
>> #endif
>>
>> ... and error.c compiled just fine.
>>
>
> Thanks a lot fo
On Fri, Sep 10, 2010 at 2:07 PM, Ozkan Sezer wrote:
> Well, src/driver/usbdlib_gcc.h at line around 23, I added :
>
> #if !defined(DDKAPI)
> #define DDKAPI NTAPI
> #endif
>
> ... and error.c compiled just fine.
>
Thanks a lot for the fast help. Now every files can be compiled. The linking
step f
On Fri, Sep 10, 2010 at 7:24 AM, Xiaofan Chen wrote:
> On Fri, Sep 10, 2010 at 12:16 PM, Xiaofan Chen wrote:
>> Now it is getting very close. Hopefully you guys have some idea
>> to fix this last problem. Thanks a lot.
>>
>> mc...@mcuee-pc-win7 /d/work/mingw-w64/libusb-win32-src-1.2.1.20
>> $ mak
On Fri, Sep 10, 2010 at 12:16 PM, Xiaofan Chen wrote:
> Now it is getting very close. Hopefully you guys have some idea
> to fix this last problem. Thanks a lot.
>
> mc...@mcuee-pc-win7 /d/work/mingw-w64/libusb-win32-src-1.2.1.20
> $ make driver -i
> gcc -c ./src/error.c -o error.o -O2 -Wall -mno-
1 - 100 of 115 matches
Mail list logo
