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
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
>- 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
Ozkan Sezer wrote:
On Sun, Sep 19, 2010 at 2:03 PM, Xiaofan Chen xiaof...@gmail.com
wrote:
On Sun, Sep 19, 2010 at 6:44 PM, Ozkan Sezer seze...@gmail.com
wrote:
However, MinGW does not break existing software and puts those
files inside include\ddk sub-directory. Why not MinGW-w64?
What
On Mon, Sep 20, 2010 at 8:50 PM, Earnie ear...@users.sourceforge.net 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.
2010/9/20 Earnie ear...@users.sourceforge.net:
Ozkan Sezer wrote:
On Sun, Sep 19, 2010 at 2:03 PM, Xiaofan Chen xiaof...@gmail.com
wrote:
On Sun, Sep 19, 2010 at 6:44 PM, Ozkan Sezer seze...@gmail.com
wrote:
However, MinGW does not break existing software and puts those
files inside
On Mon, Sep 20, 2010 at 4:03 PM, Xiaofan Chen xiaof...@gmail.com wrote:
On Mon, Sep 20, 2010 at 8:50 PM, Earnie ear...@users.sourceforge.net 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
On Mon, Sep 20, 2010 at 9:57 PM, Ozkan Sezer seze...@gmail.com wrote:
On Mon, Sep 20, 2010 at 4:03 PM, Xiaofan Chen xiaof...@gmail.com 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
On Sun, Sep 19, 2010 at 6:34 AM, Xiaofan Chen xiaof...@gmail.com wrote:
On Sun, Sep 19, 2010 at 9:54 AM, JonY jo...@users.sourceforge.net 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?
On Sun, Sep 19, 2010 at 1:11 PM, Xiaofan Chen xiaof...@gmail.com wrote:
On Sun, Sep 19, 2010 at 4:54 PM, Ozkan Sezer seze...@gmail.com 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
On Sun, Sep 19, 2010 at 6:18 PM, Ozkan Sezer seze...@gmail.com 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,
On Sun, Sep 19, 2010 at 1:40 PM, Xiaofan Chen xiaof...@gmail.com wrote:
On Sun, Sep 19, 2010 at 6:18 PM, Ozkan Sezer seze...@gmail.com 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
On Sun, Sep 19, 2010 at 6:44 PM, Ozkan Sezer seze...@gmail.com 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
On Sun, Sep 19, 2010 at 2:03 PM, Xiaofan Chen xiaof...@gmail.com wrote:
On Sun, Sep 19, 2010 at 6:44 PM, Ozkan Sezer seze...@gmail.com 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
2010/9/19 Ozkan Sezer seze...@gmail.com:
On Sun, Sep 19, 2010 at 2:03 PM, Xiaofan Chen xiaof...@gmail.com wrote:
On Sun, Sep 19, 2010 at 6:44 PM, Ozkan Sezer seze...@gmail.com wrote:
However, MinGW does not break existing software and puts
those files inside include\ddk sub-directory. Why not
On Sun, Sep 19, 2010 at 8:28 PM, Kai Tietz ktiet...@googlemail.com wrote:
2010/9/19 Ozkan Sezer seze...@gmail.com:
On Sun, Sep 19, 2010 at 2:03 PM, Xiaofan Chen xiaof...@gmail.com wrote:
On Sun, Sep 19, 2010 at 6:44 PM, Ozkan Sezer seze...@gmail.com wrote:
However, MinGW does not break
On Mon, Sep 20, 2010 at 1:28 AM, Kai Tietz ktiet...@googlemail.com 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
On Sun, Sep 19, 2010 at 2:38 AM, Xiaofan Chen xiaof...@gmail.com wrote:
On Sun, Sep 12, 2010 at 5:34 PM, Xiaofan Chen xiaof...@gmail.com wrote:
On Thu, Sep 9, 2010 at 3:53 AM, Ozkan Sezer seze...@gmail.com wrote:
2. the name of your src/usb.h is, well, usb.h, and it conflicts, ie.
searched
On Sun, Sep 19, 2010 at 7:50 AM, Ozkan Sezer seze...@gmail.com wrote:
On Sun, Sep 19, 2010 at 2:38 AM, Xiaofan Chen xiaof...@gmail.com 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
On Sun, Sep 19, 2010 at 2:56 AM, Xiaofan Chen xiaof...@gmail.com wrote:
On Sun, Sep 19, 2010 at 7:50 AM, Ozkan Sezer seze...@gmail.com wrote:
On Sun, Sep 19, 2010 at 2:38 AM, Xiaofan Chen xiaof...@gmail.com wrote:
I think the MinGW-w64 newly included usb.h will break
many existing software
On 9/19/2010 08:00, Ozkan Sezer wrote:
On Sun, Sep 19, 2010 at 2:56 AM, Xiaofan Chenxiaof...@gmail.com wrote:
On Sun, Sep 19, 2010 at 7:50 AM, Ozkan Sezerseze...@gmail.com wrote:
On Sun, Sep 19, 2010 at 2:38 AM, Xiaofan Chenxiaof...@gmail.com wrote:
I think the MinGW-w64 newly included
On Sun, Sep 19, 2010 at 9:03 AM, JonY jo...@users.sourceforge.net 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
On Sun, Sep 19, 2010 at 9:44 AM, Xiaofan Chen xiaof...@gmail.com wrote:
On Sun, Sep 19, 2010 at 9:03 AM, JonY jo...@users.sourceforge.net 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?
On Sun, Sep 19, 2010 at 07:50, Ozkan Sezer seze...@gmail.com 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\apidir *usb*
驱动器 C
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 build.
On Sat, Sep 11, 2010 at 6:56 AM, Xiaofan Chen xiaof...@gmail.com wrote:
On Fri, Sep 10, 2010 at 4:37 PM, Kai Tietz ktiet...@googlemail.com 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
On Sat, Sep 11, 2010 at 2:44 PM, Ozkan Sezer seze...@gmail.com 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
On Sat, Sep 11, 2010 at 4:00 PM, Ozkan Sezer seze...@gmail.com 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
On Sat, Sep 11, 2010 at 8:01 PM, Kai Tietz ktiet...@googlemail.com 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
On Sat, Sep 11, 2010 at 4:00 PM, Ozkan Sezer seze...@gmail.com 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
On Sat, Sep 11, 2010 at 8:31 PM, Ozkan Sezer seze...@gmail.com 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
On Sat, Sep 11, 2010 at 3:37 PM, Xiaofan Chen xiaof...@gmail.com wrote:
On Sat, Sep 11, 2010 at 8:31 PM, Ozkan Sezer seze...@gmail.com 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
2010/9/11 Ozkan Sezer seze...@gmail.com:
On Sat, Sep 11, 2010 at 3:37 PM, Xiaofan Chen xiaof...@gmail.com wrote:
On Sat, Sep 11, 2010 at 8:31 PM, Ozkan Sezer seze...@gmail.com 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 8:43 PM, Ozkan Sezer seze...@gmail.com 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
On Sat, Sep 11, 2010 at 3:46 PM, Kai Tietz ktiet...@googlemail.com wrote:
2010/9/11 Ozkan Sezer seze...@gmail.com:
On Sat, Sep 11, 2010 at 3:37 PM, Xiaofan Chen xiaof...@gmail.com wrote:
On Sat, Sep 11, 2010 at 8:31 PM, Ozkan Sezer seze...@gmail.com wrote:
You need the @8 _and_ the leading
On Sat, Sep 11, 2010 at 3:50 PM, Pete Batard pbat...@gmail.com wrote:
On 2010.09.11 13:46, Kai Tietz wrote:
2010/9/11 Ozkan Sezerseze...@gmail.com:
On Sat, Sep 11, 2010 at 3:37 PM, Xiaofan Chenxiaof...@gmail.com wrote:
On Sat, Sep 11, 2010 at 8:31 PM, Ozkan Sezerseze...@gmail.com wrote:
You
On Sat, Sep 11, 2010 at 3:46 PM, Xiaofan Chen xiaof...@gmail.com wrote:
On Sat, Sep 11, 2010 at 8:43 PM, Ozkan Sezer seze...@gmail.com wrote:
set_configuration.o:set_configuration.c:(.text+0x1c8): undefined reference
to `U
sbd_createconfigurationreques...@8'
For this particular one, I think
On Sat, Sep 11, 2010 at 9:04 PM, Ozkan Sezer seze...@gmail.com 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?
On Sat, Sep 11, 2010 at 9:10 PM, Xiaofan Chen xiaof...@gmail.com wrote:
On Sat, Sep 11, 2010 at 9:04 PM, Ozkan Sezer seze...@gmail.com wrote:
OK, reading wdm.h more carefully, the FASTCALL declarations are
protected by an #ifdef NO_INTERLOCKED_INTRINSICS guard: For x86,
can you please
On Sat, Sep 11, 2010 at 4:15 PM, Xiaofan Chen xiaof...@gmail.com wrote:
On Sat, Sep 11, 2010 at 9:10 PM, Xiaofan Chen xiaof...@gmail.com wrote:
On Sat, Sep 11, 2010 at 9:04 PM, Ozkan Sezer seze...@gmail.com wrote:
OK, reading wdm.h more carefully, the FASTCALL declarations are
protected by an
2010/9/11 Ozkan Sezer seze...@gmail.com:
On Sat, Sep 11, 2010 at 4:15 PM, Xiaofan Chen xiaof...@gmail.com wrote:
On Sat, Sep 11, 2010 at 9:10 PM, Xiaofan Chen xiaof...@gmail.com wrote:
On Sat, Sep 11, 2010 at 9:04 PM, Ozkan Sezer seze...@gmail.com wrote:
OK, reading wdm.h more carefully, the
On Sat, Sep 11, 2010 at 4:39 PM, Kai Tietz ktiet...@googlemail.com wrote:
2010/9/11 Ozkan Sezer seze...@gmail.com:
On Sat, Sep 11, 2010 at 4:15 PM, Xiaofan Chen xiaof...@gmail.com wrote:
On Sat, Sep 11, 2010 at 9:10 PM, Xiaofan Chen xiaof...@gmail.com wrote:
On Sat, Sep 11, 2010 at 9:04 PM,
On Sat, Sep 11, 2010 at 9:36 PM, Ozkan Sezer seze...@gmail.com 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
On Sun, Sep 12, 2010 at 11:38 AM, Xiaofan Chen xiaof...@gmail.com wrote:
On Sat, Sep 11, 2010 at 9:36 PM, Ozkan Sezer seze...@gmail.com 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
On Sun, Sep 12, 2010 at 11:52 AM, Xiaofan Chen xiaof...@gmail.com 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
On Fri, Sep 10, 2010 at 7:24 AM, Xiaofan Chen xiaof...@gmail.com wrote:
On Fri, Sep 10, 2010 at 12:16 PM, Xiaofan Chen xiaof...@gmail.com 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
On Fri, Sep 10, 2010 at 2:07 PM, Ozkan Sezer seze...@gmail.com 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
2010/9/10 Teemu Nätkinniemi stink...@yahoo.com:
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):
On Fri, Sep 10, 2010 at 9:52 AM, Ozkan Sezer seze...@gmail.com wrote:
On Fri, Sep 10, 2010 at 9:47 AM, Xiaofan Chen xiaof...@gmail.com wrote:
On Fri, Sep 10, 2010 at 2:07 PM, Ozkan Sezer seze...@gmail.com wrote:
Well, src/driver/usbdlib_gcc.h at line around 23, I added :
#if !defined(DDKAPI)
On Fri, Sep 10, 2010 at 10:28 AM, Kai Tietz ktiet...@googlemail.com wrote:
2010/9/10 Teemu Nätkinniemi stink...@yahoo.com:
libusb_driver.o:libusb_driver.c:(.text+0x6a9): undefined
reference to `_Interloc
kedIncrement'
libusb_driver.o:libusb_driver.c:(.text+0x6d4): undefined
reference to
2010/9/10 Ozkan Sezer seze...@gmail.com:
On Fri, Sep 10, 2010 at 10:28 AM, Kai Tietz ktiet...@googlemail.com wrote:
2010/9/10 Teemu Nätkinniemi stink...@yahoo.com:
libusb_driver.o:libusb_driver.c:(.text+0x6a9): undefined
reference to `_Interloc
kedIncrement'
2010/9/10 Xiaofan Chen xiaof...@gmail.com:
On Fri, Sep 10, 2010 at 3:29 PM, Ozkan Sezer seze...@gmail.com 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
On Fri, Sep 10, 2010 at 3:34 PM, Kai Tietz ktiet...@googlemail.com 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
On Fri, Sep 10, 2010 at 10:34 AM, Kai Tietz ktiet...@googlemail.com wrote:
2010/9/10 Ozkan Sezer seze...@gmail.com:
On Fri, Sep 10, 2010 at 10:28 AM, Kai Tietz ktiet...@googlemail.com wrote:
2010/9/10 Teemu Nätkinniemi stink...@yahoo.com:
libusb_driver.o:libusb_driver.c:(.text+0x6a9):
On Fri, Sep 10, 2010 at 10:54 AM, Kai Tietz ktiet...@googlemail.com wrote:
2010/9/10 Ozkan Sezer seze...@gmail.com:
On Fri, Sep 10, 2010 at 10:34 AM, Kai Tietz ktiet...@googlemail.com wrote:
2010/9/10 Ozkan Sezer seze...@gmail.com:
On Fri, Sep 10, 2010 at 10:28 AM, Kai Tietz
2010/9/10 Ozkan Sezer seze...@gmail.com:
On Fri, Sep 10, 2010 at 10:54 AM, Kai Tietz ktiet...@googlemail.com wrote:
2010/9/10 Ozkan Sezer seze...@gmail.com:
On Fri, Sep 10, 2010 at 10:34 AM, Kai Tietz ktiet...@googlemail.com wrote:
2010/9/10 Ozkan Sezer seze...@gmail.com:
On Fri, Sep 10, 2010
On Fri, Sep 10, 2010 at 3:59 PM, Ozkan Sezer seze...@gmail.com 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
On Fri, Sep 10, 2010 at 11:15 AM, Xiaofan Chen xiaof...@gmail.com wrote:
On Fri, Sep 10, 2010 at 3:59 PM, Ozkan Sezer seze...@gmail.com 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
2010/9/10 Xiaofan Chen xiaof...@gmail.com:
On Fri, Sep 10, 2010 at 3:59 PM, Ozkan Sezer seze...@gmail.com 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
On Fri, Sep 10, 2010 at 4:18 PM, Kai Tietz ktiet...@googlemail.com 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
On Fri, Sep 10, 2010 at 4:21 PM, Xiaofan Chen xiaof...@gmail.com wrote:
On Fri, Sep 10, 2010 at 4:18 PM, Kai Tietz ktiet...@googlemail.com 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
On Fri, Sep 10, 2010 at 11:02 AM, Kai Tietz ktiet...@googlemail.com wrote:
2010/9/10 Ozkan Sezer seze...@gmail.com:
On Fri, Sep 10, 2010 at 10:54 AM, Kai Tietz ktiet...@googlemail.com wrote:
2010/9/10 Ozkan Sezer seze...@gmail.com:
On Fri, Sep 10, 2010 at 10:34 AM, Kai Tietz
2010/9/10 Ozkan Sezer seze...@gmail.com:
On Fri, Sep 10, 2010 at 11:02 AM, Kai Tietz ktiet...@googlemail.com wrote:
2010/9/10 Ozkan Sezer seze...@gmail.com:
On Fri, Sep 10, 2010 at 10:54 AM, Kai Tietz ktiet...@googlemail.com wrote:
2010/9/10 Ozkan Sezer seze...@gmail.com:
On Fri, Sep 10, 2010
On Fri, Sep 10, 2010 at 4:27 PM, Xiaofan Chen xiaof...@gmail.com 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
2010/9/10 Xiaofan Chen xiaof...@gmail.com:
On Fri, Sep 10, 2010 at 4:27 PM, Xiaofan Chen xiaof...@gmail.com 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.
On Fri, Sep 10, 2010 at 5:43 PM, Kai Tietz ktiet...@googlemail.com 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
2010/9/10 Ozkan Sezer seze...@gmail.com:
On Fri, Sep 10, 2010 at 12:59 PM, Xiaofan Chen xiaof...@gmail.com wrote:
On Fri, Sep 10, 2010 at 5:43 PM, Kai Tietz ktiet...@googlemail.com wrote:
Unfortunately it does not work under Windows 7 x64.
I got the following error.
Windows cannot load the
On Fri, Sep 10, 2010 at 1:11 PM, Kai Tietz ktiet...@googlemail.com wrote:
2010/9/10 Ozkan Sezer seze...@gmail.com:
On Fri, Sep 10, 2010 at 12:59 PM, Xiaofan Chen xiaof...@gmail.com wrote:
On Fri, Sep 10, 2010 at 5:43 PM, Kai Tietz ktiet...@googlemail.com wrote:
Unfortunately it does not work
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
On Fri, Sep 10, 2010 at 1:18 PM, Ozkan Sezer seze...@gmail.com wrote:
On Fri, Sep 10, 2010 at 1:11 PM, Kai Tietz ktiet...@googlemail.com wrote:
2010/9/10 Ozkan Sezer seze...@gmail.com:
On Fri, Sep 10, 2010 at 12:59 PM, Xiaofan Chen xiaof...@gmail.com wrote:
On Fri, Sep 10, 2010 at 5:43 PM, Kai
On Fri, Sep 10, 2010 at 6:31 PM, Ozkan Sezer seze...@gmail.com 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
On Fri, Sep 10, 2010 at 1:34 PM, Xiaofan Chen xiaof...@gmail.com wrote:
On Fri, Sep 10, 2010 at 6:31 PM, Ozkan Sezer seze...@gmail.com 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
On Fri, Sep 10, 2010 at 6:40 PM, Ozkan Sezer seze...@gmail.com wrote:
On Fri, Sep 10, 2010 at 1:34 PM, Xiaofan Chen xiaof...@gmail.com wrote:
On Fri, Sep 10, 2010 at 6:31 PM, Ozkan Sezer seze...@gmail.com wrote:
Speaking of linkage to usbd.sys, where did you get libusbd.a for linking
to it?
On Fri, Sep 10, 2010 at 5:21 PM, Xiaofan Chen xiaof...@gmail.com wrote:
On Fri, Sep 10, 2010 at 6:40 PM, Ozkan Sezer seze...@gmail.com wrote:
On Fri, Sep 10, 2010 at 1:34 PM, Xiaofan Chen xiaof...@gmail.com wrote:
On Fri, Sep 10, 2010 at 6:31 PM, Ozkan Sezer seze...@gmail.com wrote:
Speaking
On Fri, Sep 10, 2010 at 5:59 PM, Xiaofan Chen xiaof...@gmail.com wrote:
Not sure here, it could be here undefined references DLLs, or
unavailable API. You can check imports here by using objdump -x
driver to see more details.
I will check that.
Even though the issue seems to be solved, I
On Fri, Sep 10, 2010 at 10:16 PM, Travis travis_robin...@comcast.net 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
On 9/10/2010 22:54, Xiaofan Chen wrote:
On Fri, Sep 10, 2010 at 10:16 PM, Travistravis_robin...@comcast.net 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
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!
On Fri, Sep 10, 2010 at 4:37 PM, Kai Tietz ktiet...@googlemail.com 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
On Thu, Sep 9, 2010 at 7:50 AM, Xiaofan Chen xiaof...@gmail.com wrote:
On Thu, Sep 9, 2010 at 3:53 AM, Ozkan Sezer seze...@gmail.com wrote:
I made some progress: I checked out branches/libusb-testing/ from
your libusb-win32 svn, I tried compiling src/driver/abort_endpoint.c
and it succeeded
On Wed, Sep 8, 2010 at 1:22 PM, Xiaofan Chen xiaof...@gmail.com wrote:
On Wed, Sep 8, 2010 at 1:16 PM, Ozkan Sezer seze...@gmail.com wrote:
See
http://mingw-w64.svn.sourceforge.net/viewvc/mingw-w64/experimental/ddk_test/
I'd say take
On Wed, Sep 8, 2010 at 5:12 PM, Xiaofan Chen xiaof...@gmail.com wrote:
On Wed, Sep 8, 2010 at 1:22 PM, Xiaofan Chen xiaof...@gmail.com wrote:
On Wed, Sep 8, 2010 at 1:16 PM, Ozkan Sezer seze...@gmail.com wrote:
See
http://mingw-w64.svn.sourceforge.net/viewvc/mingw-w64/experimental/ddk_test/
On Thu, Sep 9, 2010 at 3:53 AM, Ozkan Sezer seze...@gmail.com wrote:
I made some progress: I checked out branches/libusb-testing/ from
your libusb-win32 svn, I tried compiling src/driver/abort_endpoint.c
and it succeeded with the following changes:
1. one thing causing the mess was the
On Wed, Sep 8, 2010 at 4:13 AM, Xiaofan Chen xiaof...@gmail.com wrote:
On Tue, Sep 7, 2010 at 11:13 PM, Ozkan Sezer seze...@gmail.com wrote:
On Tue, Sep 7, 2010 at 6:02 PM, Xiaofan Chen xiaof...@gmail.com wrote:
I am not using the ddk from mingw.org. I am using the TDM64 version.
I believe the
On Wed, Sep 8, 2010 at 1:16 PM, Ozkan Sezer seze...@gmail.com wrote:
See
http://mingw-w64.svn.sourceforge.net/viewvc/mingw-w64/experimental/ddk_test/
I'd say take
http://mingw-w64.svn.sourceforge.net/viewvc/mingw-w64/experimental/ddk_test/include/ddk/
from there and put it into its
85 matches
Mail list logo
