[Libusb-devel] MinGW-W64 build of libusb-1.0 Windows Backend

[Xiaofan Chen]

and the basic documentation of how to build libusb-1.0 Windows
backend is not there (what to download, what to install, how to
setup MSYS, etc).

As I understand it is not different from "plain" MinGW.
When cross-compiling, I run ./configure --host=i686-w64-mingw32
or ./configure --host=x86_64-w64-mingw32 for MinGW-W64, instead
of ./configure --host=i686-mingw32 like I do with "plain" MinGW.

Last time I downloaded the following file from SourceForge.
mingw-w64-bin_i686-mingw_20100320.zip
Supposedly it is targeting 64bit system but hosted on 32bit
system. So I think it should be the right one to use.

I still need to use the normal MSys/MinGW32 to bootstrap
as there are auto-tools packages in the above zip file. Not
so sure if this is okay or not. I have not downloaded the
other necessary packages for the mingw-w64 yet. This
seems to still cause problem for the Locale issues.

The process does produce 64bit examples -- I have not tested it though
under the 64bit Windows.

***@ACERPC /c/cygwin/home/mcuee/mcu/libusb1win32/git/mingw2/libusb-pbatard
$ LC_ALL=C; LANGUAGE=C; export LANGUAGE LC_ALL

***@ACERPC /c/cygwin/home/mcuee/mcu/libusb1win32/git/mingw2/libusb-pbatard
$ LANG=C; export LANG

***@ACERPC /c/cygwin/home/mcuee/mcu/libusb1win32/git/mingw2/libusb-pbatard
$ env | grep LANG
REGINA_LANG_DIR=c:\Regina
LANG=C
REGINA_LANG=en
LANGUAGE=C

***@ACERPC /c/cygwin/home/mcuee/mcu/libusb1win32/git/mingw2/libusb-pbatard
$ ./configure --host=x86_64-w64-mingw32 --enable-examples-build
configure: WARNING: If you wanted to set the --build type, don't use --host.
If a cross compiler is detected then cross compile mode will be used.
checking for a BSD-compatible install... /bin/install -c
checking whether build environment is sane... yes
checking for x86_64-w64-mingw32-strip... x86_64-w64-mingw32-strip
checking for a thread-safe mkdir -p... /bin/mkdir -p
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking for x86_64-w64-mingw32-gcc... x86_64-w64-mingw32-gcc
checking for C compiler default output file name... a.exe
checking whether the C compiler works... yes
checking whether we are cross compiling... yes
checking for suffix of executables... .exe
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether x86_64-w64-mingw32-gcc accepts -g... yes
checking for x86_64-w64-mingw32-gcc option to accept ISO C89... none needed
checking for style of include used by make... GNU
checking dependency style of x86_64-w64-mingw32-gcc... gcc3
checking build system type... i686-pc-mingw32
checking host system type... x86_64-w64-mingw32
checking how to print strings... printf
checking for a sed that does not truncate output... /bin/sed
checking for grep that handles long lines and -e... /bin/grep
checking for egrep... /bin/grep -E
checking for fgrep... /bin/grep -F
checking for ld used by x86_64-w64-mingw32-gcc... d:/mingw-w64/x86_64-w64-mingw3
2/bin/ld.exe
checking if the linker (d:/mingw-w64/x86_64-w64-mingw32/bin/ld.exe) is GNU ld...
yes
checking for BSD- or MS-compatible name lister (nm)... /d/mingw-w64/bin/x86_64-w
64-mingw32-nm
checking the name lister (/d/mingw-w64/bin/x86_64-w64-mingw32-nm) interface... B
SD nm
checking whether ln -s works... no, using cp -p
checking the maximum length of command line arguments... 8192
checking whether the shell understands some XSI constructs... yes
checking whether the shell understands "+="... yes
checking how to convert i686-pc-mingw32 paths to x86_64-w64-mingw32 format... fu
nc_msys_to_mingw_path_convert
checking for d:/mingw-w64/x86_64-w64-mingw32/bin/ld.exe option to reload object
files... -r
checking for x86_64-w64-mingw32-objdump... x86_64-w64-mingw32-objdump
checking how to recognize dependent libraries... file_magic ^x86 archive import|
^x86 DLL
checking for x86_64-w64-mingw32-dlltool... x86_64-w64-mingw32-dlltool
checking how to associate runtime and link libraries... func_cygming_dll_for_imp
lib
checking for x86_64-w64-mingw32-ar... x86_64-w64-mingw32-ar
checking for x86_64-w64-mingw32-strip... (cached) x86_64-w64-mingw32-strip
checking for x86_64-w64-mingw32-ranlib... x86_64-w64-mingw32-ranlib
checking command to parse /d/mingw-w64/bin/x86_64-w64-mingw32-nm output from x86
_64-w64-mingw32-gcc object... ok
checking how to run the C preprocessor... x86_64-w64-mingw32-gcc -E
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking for dlfcn.h... yes
checking for objdir... .libs
checking if x86_64-w64-mingw32-gcc supports -fno-rtti -fno-exceptions... no
checking for x86_64-w64-mingw32-gcc option to produce PIC... -DDLL_EXPORT -DPIC
checking if x86_64-w64-mingw32-gcc PIC flag -DDLL_EXPORT -DPIC works... yes
checking if x86_64-w64-mingw32-gcc static flag -static works... yes
checking if x86_64-w64-mingw32-gcc supports -c -o file.o... yes
checking if x86_64-w64-mingw32-gcc supports -c -o file.o... (cached) yes
checking whether the x86_64-w64-mingw32-gcc linker (d:/mingw-w64/x86_64-w64-ming
w32/bin/ld.exe) supports shared libraries... yes
checking whether -lc should be explicitly linked in... yes
checking dynamic linker characteristics... Win32 ld.exe
checking how to hardcode library paths into programs... immediate
checking whether stripping libraries is possible... yes
checking if libtool supports shared libraries... yes
checking whether to build shared libraries... yes
checking whether to build static libraries... yes
checking for inline... inline
checking whether x86_64-w64-mingw32-gcc and cc understand -c and -o together...
yes
checking operating system... Windows
checking for x86_64-w64-mingw32-windres... x86_64-w64-mingw32-windres
checking sys/timerfd.h usability... no
checking sys/timerfd.h presence... no
checking for sys/timerfd.h... no
checking whether TFD_NONBLOCK is declared... no
checking whether to use timerfd for timing... no (header not available)
checking for struct timespec... yes
configure: creating ./config.status
config.status: creating libusb-1.0.pc
config.status: creating Makefile
config.status: creating libusb/Makefile
config.status: creating libusb/libusb-1.0.rc
config.status: creating examples/Makefile
config.status: creating doc/Makefile
config.status: creating doc/doxygen.cfg
config.status: creating config.h
config.status: config.h is unchanged
config.status: executing depfiles commands
config.status: executing libtool commands

***@ACERPC /c/cygwin/home/mcuee/mcu/libusb1win32/git/mingw2/libusb-pbatard
$ make
make all-recursive
make[1]: Entering directory `/c/cygwin/home/mcuee/mcu/libusb1win32/git/mingw2/li
busb-pbatard'
Making all in libusb
make[2]: Entering directory `/c/cygwin/home/mcuee/mcu/libusb1win32/git/mingw2/li
busb-pbatard/libusb'
CC libusb_1_0_la-core.lo
CC libusb_1_0_la-descriptor.lo
CC libusb_1_0_la-io.lo
io.c: In function 'get_next_timeout':
io.c:1917:3: warning: suggest parentheses around '&&' within '||'
io.c: In function 'libusb_get_next_timeout':
io.c:2160:2: warning: suggest parentheses around '&&' within '||'
CC libusb_1_0_la-sync.lo
CC libusb_1_0_la-threads_windows.lo
CC libusb_1_0_la-poll_windows.lo
CC libusb_1_0_la-windows_usb.lo
os/windows_usb.c: In function 'winusb_submit_control_transfer':
os/windows_usb.c:2546:30: warning: unused variable 'priv'
os/windows_usb.c: In function 'hid_submit_control_transfer':
os/windows_usb.c:3650:25: warning: unused variable 'ctx'
/bin/sh ../libtool --mode=compile x86_64-w64-mingw32-windres -i libusb-1.0.rc
-o libusb-1.0.lo
libtool: compile: x86_64-w64-mingw32-windres -i libusb-1.0.rc -DDLL_EXPORT -DP
IC -o .libs/libusb-1.0.o
libtool: compile: x86_64-w64-mingw32-windres -i libusb-1.0.rc -o libusb-1.0.o >
/dev/null 2>&1
CCLD libusb-1.0.la

*** Warning: linker path does not have real file for library -lsetupapi.
*** I have the capability to make that library automatically link in when
*** you link to this library. But I can only do this if you have a
*** shared version of the library, which you do not appear to have
*** because I did check the linker path looking for a file starting
*** with libsetupapi but no candidates were found. (...for file magic test)

*** Warning: linker path does not have real file for library -lole32.
*** I have the capability to make that library automatically link in when
*** you link to this library. But I can only do this if you have a
*** shared version of the library, which you do not appear to have
*** because I did check the linker path looking for a file starting
*** with libole32 but no candidates were found. (...for file magic test)

*** Warning: linker path does not have real file for library -ladvapi32.
*** I have the capability to make that library automatically link in when
*** you link to this library. But I can only do this if you have a
*** shared version of the library, which you do not appear to have
*** because I did check the linker path looking for a file starting
*** with libadvapi32 but no candidates were found. (...for file magic test)
*** The inter-library dependencies that have been dropped here will be
*** automatically added whenever a program is linked with this library
*** or is declared to -dlopen it.

*** Since this library must not contain undefined symbols,
*** because either the platform does not support them or
*** it was explicitly requested with -no-undefined,
*** libtool will only create a static version of it.
make[2]: Leaving directory `/c/cygwin/home/mcuee/mcu/libusb1win32/git/mingw2/lib
usb-pbatard/libusb'
Making all in doc
make[2]: Entering directory `/c/cygwin/home/mcuee/mcu/libusb1win32/git/mingw2/li
busb-pbatard/doc'
make[2]: Nothing to be done for `all'.
make[2]: Leaving directory `/c/cygwin/home/mcuee/mcu/libusb1win32/git/mingw2/lib
usb-pbatard/doc'
Making all in examples
make[2]: Entering directory `/c/cygwin/home/mcuee/mcu/libusb1win32/git/mingw2/li
busb-pbatard/examples'
CC xusb.o
CCLD xusb.exe
CC lsusb.o
CCLD lsusb.exe
CC dpfp.o
CCLD dpfp.exe
make[2]: Leaving directory `/c/cygwin/home/mcuee/mcu/libusb1win32/git/mingw2/lib
usb-pbatard/examples'
make[2]: Entering directory `/c/cygwin/home/mcuee/mcu/libusb1win32/git/mingw2/li
busb-pbatard'
make[2]: Leaving directory `/c/cygwin/home/mcuee/mcu/libusb1win32/git/mingw2/lib
usb-pbatard'
make[1]: Leaving directory `/c/cygwin/home/mcuee/mcu/libusb1win32/git/mingw2/lib
usb-pbatard'

[Xiaofan Chen]

Post by Xiaofan Chen
Last time I downloaded the following file from SourceForge.
mingw-w64-bin_i686-mingw_20100320.zip
Supposedly it is targeting 64bit system but hosted on 32bit
system. So I think it should be the right one to use.
I still need to use the normal MSys/MinGW32 to bootstrap
as there are auto-tools packages in the above zip file. Not
so sure if this is okay or not. I have not downloaded the
other necessary packages for the mingw-w64 yet. This
seems to still cause problem for the Locale issues.
The process does produce 64bit examples -- I have not tested it though
under the 64bit Windows.

So I set the locale back to US English and reboot. It still has the
issue. Maybe the 32bit libtool is the issue as the mingw-w64
does not seem to provide the libtool package.

I will try the WPG64 system later. It seems to only run under
64bit Windows.

***@ACERPC /c/cygwin/home/mcuee/mcu/libusb1win32/git/mingw2/libusb-pbatard
$ ./autogen.sh --host=x86_64-w64-mingw32 --enable-examples-build
libtoolize: putting auxiliary files in `.'.
libtoolize: copying file `./ltmain.sh'
libtoolize: putting macros in AC_CONFIG_MACRO_DIR, `m4'.
libtoolize: copying file `m4/libtool.m4'
libtoolize: copying file `m4/ltoptions.m4'
libtoolize: copying file `m4/ltsugar.m4'
libtoolize: copying file `m4/ltversion.m4'
libtoolize: copying file `m4/lt~obsolete.m4'
configure: WARNING: If you wanted to set the --build type, don't use --host.
If a cross compiler is detected then cross compile mode will be used.
checking for a BSD-compatible install... /bin/install -c
checking whether build environment is sane... yes
checking for x86_64-w64-mingw32-strip... x86_64-w64-mingw32-strip
checking for a thread-safe mkdir -p... /bin/mkdir -p
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking for x86_64-w64-mingw32-gcc... x86_64-w64-mingw32-gcc
checking for C compiler default output file name... a.exe
checking whether the C compiler works... yes
checking whether we are cross compiling... yes
checking for suffix of executables... .exe
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether x86_64-w64-mingw32-gcc accepts -g... yes
checking for x86_64-w64-mingw32-gcc option to accept ISO C89... none needed
checking for style of include used by make... GNU
checking dependency style of x86_64-w64-mingw32-gcc... gcc3
checking build system type... i686-pc-mingw32
checking host system type... x86_64-w64-mingw32
checking how to print strings... printf
checking for a sed that does not truncate output... /bin/sed
checking for grep that handles long lines and -e... /bin/grep
checking for egrep... /bin/grep -E
checking for fgrep... /bin/grep -F
checking for ld used by x86_64-w64-mingw32-gcc... d:/mingw-w64/x86_64-w64-mingw3
2/bin/ld.exe
checking if the linker (d:/mingw-w64/x86_64-w64-mingw32/bin/ld.exe) is GNU ld...
yes
checking for BSD- or MS-compatible name lister (nm)... /d/mingw-w64/bin//x86_64-
w64-mingw32-nm
checking the name lister (/d/mingw-w64/bin//x86_64-w64-mingw32-nm) interface...
BSD nm
checking whether ln -s works... no, using cp -p
checking the maximum length of command line arguments... 8192
checking whether the shell understands some XSI constructs... yes
checking whether the shell understands "+="... yes
checking how to convert i686-pc-mingw32 paths to x86_64-w64-mingw32 format... fu
nc_msys_to_mingw_path_convert
checking for d:/mingw-w64/x86_64-w64-mingw32/bin/ld.exe option to reload object
files... -r
checking for x86_64-w64-mingw32-objdump... x86_64-w64-mingw32-objdump
checking how to recognize dependent libraries... file_magic ^x86 archive import|
^x86 DLL
checking for x86_64-w64-mingw32-dlltool... x86_64-w64-mingw32-dlltool
checking how to associate runtime and link libraries... func_cygming_dll_for_imp
lib
checking for x86_64-w64-mingw32-ar... x86_64-w64-mingw32-ar
checking for x86_64-w64-mingw32-strip... (cached) x86_64-w64-mingw32-strip
checking for x86_64-w64-mingw32-ranlib... x86_64-w64-mingw32-ranlib
checking command to parse /d/mingw-w64/bin//x86_64-w64-mingw32-nm output from x8
6_64-w64-mingw32-gcc object... ok
checking how to run the C preprocessor... x86_64-w64-mingw32-gcc -E
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking for dlfcn.h... yes
checking for objdir... .libs
checking if x86_64-w64-mingw32-gcc supports -fno-rtti -fno-exceptions... no
checking for x86_64-w64-mingw32-gcc option to produce PIC... -DDLL_EXPORT -DPIC
checking if x86_64-w64-mingw32-gcc PIC flag -DDLL_EXPORT -DPIC works... yes
checking if x86_64-w64-mingw32-gcc static flag -static works... yes
checking if x86_64-w64-mingw32-gcc supports -c -o file.o... yes
checking if x86_64-w64-mingw32-gcc supports -c -o file.o... (cached) yes
checking whether the x86_64-w64-mingw32-gcc linker (d:/mingw-w64/x86_64-w64-ming
w32/bin/ld.exe) supports shared libraries... yes
checking whether -lc should be explicitly linked in... yes
checking dynamic linker characteristics... Win32 ld.exe
checking how to hardcode library paths into programs... immediate
checking whether stripping libraries is possible... yes
checking if libtool supports shared libraries... yes
checking whether to build shared libraries... yes
checking whether to build static libraries... yes
checking for inline... inline
checking whether x86_64-w64-mingw32-gcc and cc understand -c and -o together...
yes
checking operating system... Windows
checking for x86_64-w64-mingw32-windres... x86_64-w64-mingw32-windres
checking sys/timerfd.h usability... no
checking sys/timerfd.h presence... no
checking for sys/timerfd.h... no
checking whether TFD_NONBLOCK is declared... no
checking whether to use timerfd for timing... no (header not available)
checking for struct timespec... yes
configure: creating ./config.status
config.status: creating libusb-1.0.pc
config.status: creating Makefile
config.status: creating libusb/Makefile
config.status: creating libusb/libusb-1.0.rc
config.status: creating examples/Makefile
config.status: creating doc/Makefile
config.status: creating doc/doxygen.cfg
config.status: creating config.h
config.status: executing depfiles commands
config.status: executing libtool commands

***@ACERPC /c/cygwin/home/mcuee/mcu/libusb1win32/git/mingw2/libusb-pbatard
$ make
(CDPATH="${ZSH_VERSION+.}:" && cd . && /bin/sh /c/cygwin/home/mcuee/mcu/libusb1w
in32/git/mingw2/libusb-pbatard/missing --run autoheader)
rm -f stamp-h1
touch config.h.in
cd . && /bin/sh ./config.status config.h
config.status: creating config.h
config.status: config.h is unchanged
make all-recursive
make[1]: Entering directory `/c/cygwin/home/mcuee/mcu/libusb1win32/git/mingw2/li
busb-pbatard'
Making all in libusb
make[2]: Entering directory `/c/cygwin/home/mcuee/mcu/libusb1win32/git/mingw2/li
busb-pbatard/libusb'
CC libusb_1_0_la-core.lo
CC libusb_1_0_la-descriptor.lo
CC libusb_1_0_la-io.lo
io.c: In function 'get_next_timeout':
io.c:1917:3: warning: suggest parentheses around '&&' within '||'
io.c: In function 'libusb_get_next_timeout':
io.c:2160:2: warning: suggest parentheses around '&&' within '||'
CC libusb_1_0_la-sync.lo
CC libusb_1_0_la-threads_windows.lo
CC libusb_1_0_la-poll_windows.lo
CC libusb_1_0_la-windows_usb.lo
os/windows_usb.c: In function 'winusb_submit_control_transfer':
os/windows_usb.c:2546:30: warning: unused variable 'priv'
os/windows_usb.c: In function 'hid_submit_control_transfer':
os/windows_usb.c:3650:25: warning: unused variable 'ctx'
/bin/sh ../libtool --mode=compile x86_64-w64-mingw32-windres -i libusb-1.0.rc
-o libusb-1.0.lo
libtool: compile: x86_64-w64-mingw32-windres -i libusb-1.0.rc -DDLL_EXPORT -DP
IC -o .libs/libusb-1.0.o
libtool: compile: x86_64-w64-mingw32-windres -i libusb-1.0.rc -o libusb-1.0.o >
/dev/null 2>&1
CCLD libusb-1.0.la

*** Warning: linker path does not have real file for library -lsetupapi.
*** I have the capability to make that library automatically link in when
*** you link to this library. But I can only do this if you have a
*** shared version of the library, which you do not appear to have
*** because I did check the linker path looking for a file starting
*** with libsetupapi but no candidates were found. (...for file magic test)

*** Warning: linker path does not have real file for library -lole32.
*** I have the capability to make that library automatically link in when
*** you link to this library. But I can only do this if you have a
*** shared version of the library, which you do not appear to have
*** because I did check the linker path looking for a file starting
*** with libole32 but no candidates were found. (...for file magic test)

*** Warning: linker path does not have real file for library -ladvapi32.
*** I have the capability to make that library automatically link in when
*** you link to this library. But I can only do this if you have a
*** shared version of the library, which you do not appear to have
*** because I did check the linker path looking for a file starting
*** with libadvapi32 but no candidates were found. (...for file magic test)
*** The inter-library dependencies that have been dropped here will be
*** automatically added whenever a program is linked with this library
*** or is declared to -dlopen it.

*** Since this library must not contain undefined symbols,
*** because either the platform does not support them or
*** it was explicitly requested with -no-undefined,
*** libtool will only create a static version of it.
make[2]: Leaving directory `/c/cygwin/home/mcuee/mcu/libusb1win32/git/mingw2/lib
usb-pbatard/libusb'
Making all in doc
make[2]: Entering directory `/c/cygwin/home/mcuee/mcu/libusb1win32/git/mingw2/li
busb-pbatard/doc'
make[2]: Nothing to be done for `all'.
make[2]: Leaving directory `/c/cygwin/home/mcuee/mcu/libusb1win32/git/mingw2/lib
usb-pbatard/doc'
Making all in examples
make[2]: Entering directory `/c/cygwin/home/mcuee/mcu/libusb1win32/git/mingw2/li
busb-pbatard/examples'
CC xusb.o
CCLD xusb.exe
CCLD lsusb.exe
CCLD dpfp.exe
make[2]: Leaving directory `/c/cygwin/home/mcuee/mcu/libusb1win32/git/mingw2/lib
usb-pbatard/examples'
make[2]: Entering directory `/c/cygwin/home/mcuee/mcu/libusb1win32/git/mingw2/li
busb-pbatard'
make[2]: Leaving directory `/c/cygwin/home/mcuee/mcu/libusb1win32/git/mingw2/lib
usb-pbatard'
make[1]: Leaving directory `/c/cygwin/home/mcuee/mcu/libusb1win32/git/mingw2/lib
usb-pbatard'

[Xiaofan Chen]

Post by Xiaofan Chen
I will try the WPG64 system later. It seems to only run under
64bit Windows.

Other than git, it seems to have everything needed. And the
generated exe seems to work. But I am not so sure whether
the generated files are really 64bit or 32bit...

***@WIN7HOMEX64_PC /d/work/libusb1win32/mingw/libusb-pbatard
$ ./autogen.sh
libtoolize: putting auxiliary files in `.'.
libtoolize: copying file `./ltmain.sh'
libtoolize: putting macros in AC_CONFIG_MACRO_DIR, `m4'.
libtoolize: copying file `m4/libtool.m4'
libtoolize: copying file `m4/ltoptions.m4'
libtoolize: copying file `m4/ltsugar.m4'
libtoolize: copying file `m4/ltversion.m4'
libtoolize: copying file `m4/lt~obsolete.m4'
/usr/share/aclocal/aalib.m4:12: warning: underquoted definition of AM_PATH_AALIB

/usr/share/aclocal/aalib.m4:12: run info '(automake)Extending aclocal'
/usr/share/aclocal/aalib.m4:12: or see http://sources.redhat.com/automake/auto
make.html#Extending-aclocal
checking for a BSD-compatible install... /bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... /bin/mkdir -p
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking for gcc... gcc
checking for C compiler default output file name... a.exe
checking whether the C compiler works... yes
checking whether we are cross compiling... no
checking for suffix of executables... .exe
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
checking for style of include used by make... GNU
checking dependency style of gcc... gcc3
checking build system type... i686-pc-mingw32
checking host system type... i686-pc-mingw32
checking how to print strings... printf
checking for a sed that does not truncate output... /bin/sed
checking for grep that handles long lines and -e... /bin/grep
checking for egrep... /bin/grep -E
checking for fgrep... /bin/grep -F
checking for ld used by gcc... c:/msys/system64/x86_64-w64-mingw32/bin/ld.exe
checking if the linker
(c:/msys/system64/x86_64-w64-mingw32/bin/ld.exe) is GNU ld... yes
checking for BSD- or MS-compatible name lister (nm)... /usr/system64/bin/nm
checking the name lister (/usr/system64/bin/nm) interface... BSD nm
checking whether ln -s works... yes
checking the maximum length of command line arguments... 8192
checking whether the shell understands some XSI constructs... yes
checking whether the shell understands "+="... yes
checking for c:/msys/system64/x86_64-w64-mingw32/bin/ld.exe option to
reload object files... -r
checking for objdump... objdump
checking how to recognize dependent libraries... file_magic ^x86
archive import|^x86 DLL
checking for ar... ar
checking for strip... strip
checking for ranlib... ranlib
checking command to parse /usr/system64/bin/nm output from gcc object... ok
checking how to run the C preprocessor... gcc -E
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking for dlfcn.h... yes
checking for objdir... .libs
checking if gcc supports -fno-rtti -fno-exceptions... no
checking for gcc option to produce PIC... -DDLL_EXPORT -DPIC
checking if gcc PIC flag -DDLL_EXPORT -DPIC works... yes
checking if gcc static flag -static works... yes
checking if gcc supports -c -o file.o... yes
checking if gcc supports -c -o file.o... (cached) yes
checking whether the gcc linker (c:/msys/system64/x86_64-w64-mingw32/bin/ld.exe)
supports shared libraries... yes
checking whether -lc should be explicitly linked in... yes
checking dynamic linker characteristics... Win32 ld.exe
checking how to hardcode library paths into programs... immediate
checking whether stripping libraries is possible... yes
checking if libtool supports shared libraries... yes
checking whether to build shared libraries... yes
checking whether to build static libraries... yes
checking for inline... inline
checking whether gcc and cc understand -c and -o together... yes
checking operating system... Windows
checking for windres... windres
checking sys/timerfd.h usability... no
checking sys/timerfd.h presence... no
checking for sys/timerfd.h... no
checking whether TFD_NONBLOCK is declared... no
checking whether to use timerfd for timing... no (header not available)
checking for struct timespec... yes
configure: creating ./config.status
config.status: creating libusb-1.0.pc
config.status: creating Makefile
config.status: creating libusb/Makefile
config.status: creating libusb/libusb-1.0.rc
config.status: creating examples/Makefile
config.status: creating doc/Makefile
config.status: creating doc/doxygen.cfg
config.status: creating config.h
config.status: config.h is unchanged
config.status: executing depfiles commands
config.status: executing libtool commands

***@WIN7HOMEX64_PC /d/work/libusb1win32/mingw/libusb-pbatard
$ make
(CDPATH="${ZSH_VERSION+.}:" && cd . && /bin/sh /d/work/libusb1win32/mingw/libusb
-pbatard/missing --run autoheader)
rm -f stamp-h1
touch config.h.in
cd . && /bin/sh ./config.status config.h
config.status: creating config.h
config.status: config.h is unchanged
make all-recursive
make[1]: Entering directory `/d/work/libusb1win32/mingw/libusb-pbatard'
Making all in libusb
make[2]: Entering directory `/d/work/libusb1win32/mingw/libusb-pbatard/libusb'
CC libusb_1_0_la-core.lo
CC libusb_1_0_la-descriptor.lo
CC libusb_1_0_la-io.lo
io.c: In function 'get_next_timeout':
io.c:1917:3: warning: suggest parentheses around '&&' within '||'
io.c: In function 'libusb_get_next_timeout':
io.c:2160:2: warning: suggest parentheses around '&&' within '||'
CC libusb_1_0_la-sync.lo
CC libusb_1_0_la-threads_windows.lo
CC libusb_1_0_la-poll_windows.lo
CC libusb_1_0_la-windows_usb.lo
os/windows_usb.c: In function 'winusb_submit_control_transfer':
os/windows_usb.c:2546:30: warning: unused variable 'priv'
os/windows_usb.c: In function 'hid_submit_control_transfer':
os/windows_usb.c:3650:25: warning: unused variable 'ctx'
/bin/sh ../libtool --mode=compile windres -i libusb-1.0.rc -o libusb-1.0.lo
libtool: compile: windres -i libusb-1.0.rc -DDLL_EXPORT -DPIC -o .libs/libusb-
1.0.o
libtool: compile: windres -i libusb-1.0.rc -o libusb-1.0.o >/dev/null 2>&1
CCLD libusb-1.0.la
Creating library file: .libs/libusb-1.0.dll.a
make[2]: Leaving directory `/d/work/libusb1win32/mingw/libusb-pbatard/libusb'
Making all in doc
make[2]: Entering directory `/d/work/libusb1win32/mingw/libusb-pbatard/doc'
make[2]: Nothing to be done for `all'.
make[2]: Leaving directory `/d/work/libusb1win32/mingw/libusb-pbatard/doc'
Making all in examples
make[2]: Entering directory `/d/work/libusb1win32/mingw/libusb-pbatard/examples'

CC xusb.o
CCLD xusb.exe
CC lsusb.o
CCLD lsusb.exe
CC dpfp.o
CCLD dpfp.exe
make[2]: Leaving directory `/d/work/libusb1win32/mingw/libusb-pbatard/examples'
make[2]: Entering directory `/d/work/libusb1win32/mingw/libusb-pbatard'
make[2]: Leaving directory `/d/work/libusb1win32/mingw/libusb-pbatard'
make[1]: Leaving directory `/d/work/libusb1win32/mingw/libusb-pbatard'

[Samuel Thibault]

Hello,

I'm having issues with libusb_bulk_transfer() in the brltty application:
the timeout parameter is set to 20, but the call blocks until I press a
key on the device. This happens both on cygwin and on mingw. I'm using
git bd62c472.

Samuel

[Pete Batard]

Post by Samuel Thibault
the timeout parameter is set to 20, but the call blocks until I press a
key on the device. This happens both on cygwin and on mingw. I'm using
git bd62c472.

Hi Samuel,

Do you have the libusb debug output that your application generates?

If not, can you at least tell us if the USB device is using the HID
driver or WinUSB, and possibly point to a version of the source code you
are using?

Regards,

/Pete

[Samuel Thibault]

Post by Pete Batard

Post by Samuel Thibault
the timeout parameter is set to 20, but the call blocks until I press a
key on the device. This happens both on cygwin and on mingw. I'm using
git bd62c472.

Hi Samuel,
Do you have the libusb debug output that your application generates?

Attached is the full log, including the usual brltty logs, the libusb
logs, but also additional logs: awaiting Input for 200, interval 20,
looping is the path in the backtrace I talked about, bulk_transfer 20
30.765 is just before calling libusb_bulk_transfer, and represents
the timeout parameter(20) and the system clock (30s 765ms). done is
just after calling libusb_bulk_transfer, and provides only the system
clock. The long pause is marked by ***, I typed a key on the keyboard to
let it continue. Apparently the timeout length doesn't get propagated to

libusb:debug [handle_events] poll() 2 fds with timeout in 60000ms

Also, the B1 and 00 bytes that are obtained are spurious. I don't know
where they come from. When using libusb-win32 with the same virtual
hardware, they do not appear.

Post by Pete Batard
If not, can you at least tell us if the USB device is using the HID
driver or WinUSB, and possibly point to a version of the source code you
are using?

WinUSB, svn checkout svn://mielke.cc/main/brltty

Samuel

[Pete Batard]

Thanks for the log.

Post by Samuel Thibault
Apparently the timeout length doesn't get propagated to
libusb:debug [handle_events] poll() 2 fds with timeout in 60000ms

Yes. This could be a problem with timeouts that are too short expiring
before we have a chance to acknowledge them for some reason.

I need to dig this further (might take a little while). One thing that
might help there, if you can, would be to uncomment the #define
DEBUG_POLL_WINDOWS in libsub/os/poll_windows.c and recompile libusb, as
this might give us some more insight in the log on whether our poll
emulation actually sees these short timeouts or not.

Post by Samuel Thibault
Also, the B1 and 00 bytes that are obtained are spurious.

If you have a possibility to trace the USB data being transferred (using
snoopypro on XP for instance -
http://sourceforge.net/projects/usbsnoop/), you might be able to confirm
if the data actually comes from your device or from libusb.

I'll check if I there's a possibility that our code might be adding the
spurious bytes on my end.

Regards,

/Pete

[Samuel Thibault]

Post by Pete Batard

Post by Samuel Thibault
Also, the B1 and 00 bytes that are obtained are spurious.

If you have a possibility to trace the USB data being transferred (using
snoopypro on XP for instance -
http://sourceforge.net/projects/usbsnoop/), you might be able to confirm
if the data actually comes from your device or from libusb.

I'm sure it doesn't come from the device: I wrote the device emulation
code :)

Samuel

[Samuel Thibault]

Post by Pete Batard

Post by Samuel Thibault
Apparently the timeout length doesn't get propagated to
libusb:debug [handle_events] poll() 2 fds with timeout in 60000ms

Yes. This could be a problem with timeouts that are too short expiring
before we have a chance to acknowledge them for some reason.
I need to dig this further (might take a little while). One thing that
might help there, if you can, would be to uncomment the #define
DEBUG_POLL_WINDOWS in libsub/os/poll_windows.c and recompile libusb, as
this might give us some more insight in the log on whether our poll
emulation actually sees these short timeouts or not.

Here it is.

Samuel

[Samuel Thibault]

Hello,

Something that may have some importance, as apparently libusb is using
threads to simulate timeouts: when I give only one cpu to my windows,
the problem seems to go away.

That could thus just be a race condition.

Samuel

[Samuel Thibault]

Post by Samuel Thibault
Something that may have some importance, as apparently libusb is using
threads to simulate timeouts: when I give only one cpu to my windows,
the problem seems to go away.
That could thus just be a race condition.

Just to confirm my thoughts: I have added a mere
SetProcessAffinityMask() call before libusb1.0 initialization, to bind
all threads of the brltty process on a single processor, and that makes
the issue away. This really looks like a race condition between your
threads, uncovered by the fact that with multiple CPUs, they can really
run in parallel.

Samuel

[Pete Batard]

Post by Samuel Thibault
Just to confirm my thoughts: I have added a mere
SetProcessAffinityMask() call before libusb1.0 initialization, to bind
all threads of the brltty process on a single processor, and that makes
the issue away. This really looks like a race condition between your
threads, uncovered by the fact that with multiple CPUs, they can really
run in parallel.

Nice going!

If you're using cygwin, then you're using pthread-win32 rather than our
internal Windows thread emulation. There's a small chance that the
thread emulation used by MinGW and MSVC is unaffected by this issue.

Is it a possibility for you to run a test with MinGW32 and see if the
same issue occurs?

Regards,

/Pete

[Samuel Thibault]

Post by Pete Batard
Is it a possibility for you to run a test with MinGW32 and see if the
same issue occurs?

It does. And the processor binding trick cures it on MinGW32 as well.

Samuel

[Xiaofan Chen]

Post by Pete Batard
If you're using cygwin, then you're using pthread-win32 rather than our
internal Windows thread emulation. There's a small chance that the
thread emulation used by MinGW and MSVC is unaffected by this issue.

Now I just realized this one. I thought you have to explicitly enable
pthread-win32 in the config.h file but I was wrong.

Hello Samuel,

You mentioned that it worked under Linux but I am not so sure if you
are using libusb-1.0 under Linux. The Linux backend of Brltty seems
to use sysfs/usbfs directly (usb_linux.c) and not libusb-1.0.

I will suggest you to try the libusb-1.0 under Linux in Brltty if you
are using the default Brltty usb_linux.c.

This is to eliminate the *possible libusb core issue*.

[Samuel Thibault]

Post by Xiaofan Chen
You mentioned that it worked under Linux but I am not so sure if you
are using libusb-1.0 under Linux. The Linux backend of Brltty seems
to use sysfs/usbfs directly (usb_linux.c) and not libusb-1.0.

We tried all of the old libusb, libusb-1.0, and the native Linux
interface.

Samuel

[Graeme Gill]

Post by Pete Batard
If you're using cygwin, then you're using pthread-win32 rather than our
internal Windows thread emulation. There's a small chance that the
thread emulation used by MinGW and MSVC is unaffected by this issue.

Are you sure it's not the race condition in io.c that I pointed out
a week or so ago ?

Graeme Gill.

[Samuel Thibault]

Post by Samuel Thibault
Also, the B1 and 00 bytes that are obtained are spurious. I don't know
where they come from. When using libusb-win32 with the same virtual
hardware, they do not appear.

Oh, actually this looks like the standard FTDI header: CTS, DSR and RLSD
all set, RI cleared, and no error.

Samuel

[Samuel Thibault]

Post by Samuel Thibault

Post by Samuel Thibault
Also, the B1 and 00 bytes that are obtained are spurious. I don't know
where they come from. When using libusb-win32 with the same virtual
hardware, they do not appear.

Oh, actually this looks like the standard FTDI header: CTS, DSR and RLSD
all set, RI cleared, and no error.

I guess what happens is that because of timeout difficulties, brltty
doesn't enables its internal ftdi filter, thus the spurious data.

Samuel

[Pete Batard]

Hi Samuel,

I'm not forgetting about your issue. I tried to run some quick tests on
my end, but did not find issues when using small timeouts.

Post by Samuel Thibault
WinUSB, svn checkout svn://mielke.cc/main/brltty

I have now recompiled brltty to use libusb 1.0 with MinGW32 (this wasn't
too difficult, but I now realize you were using cygwin, so I might
switch to cygwin), and I believe that I should be able to install the
virtual braille device you were talking about to reproduce your issue.
My configure summary lists vr for internal-braille-drivers, and the
braille-device is set to usb)

Haven't read the doc yet, so I'm not entirely sure how to proceed from
here. Are additional files needed for the virtual driver? Can you tell
us a bit more on how you run brltty for your tests?

Regards,

/Pete

[Samuel Thibault]

Hello,

Post by Pete Batard
I'm not forgetting about your issue.

Funny, our posts actually crossed :)

Post by Pete Batard

Post by Samuel Thibault
WinUSB, svn checkout svn://mielke.cc/main/brltty

I have now recompiled brltty to use libusb 1.0 with MinGW32 (this wasn't
too difficult, but I now realize you were using cygwin, so I might
switch to cygwin)

Both mingw32 and cygwin have the issue, so use the version you are most
at ease with.

Post by Pete Batard
and I believe that I should be able to install the
virtual braille device you were talking about to reproduce your issue.
My configure summary lists vr for internal-braille-drivers, and the
braille-device is set to usb)

Ah, no that's not the same kind of virtual device :) the vr driver in
brltty is for a TCP/IP-based virtual device. In my tests, I am running
windows inside qemu, and hotplugging the virtual braille device emulated
by qemu (usb_add braille from the qemu console).

Post by Pete Batard
Haven't read the doc yet, so I'm not entirely sure how to proceed from
here.

It's not really easy to figure out just from the brltty Doc. You should
probably rather read

http://wiki.debian.org/DebianInstaller/Accessibility

which is the documentation I made for Debian people, but it should work
with windows: first start a brltty instance with the xw driver to get
a window that will show the braille output:

/sbin/brltty -b xw -x no -A auth=none,host=127.0.0.1:1

then start qemu with the braille virtual device to be exposed to the
guest (its output will go into the first brltty):

BRLAPI_HOST=127.0.0.1:1 qemu -usbdevice braille -hda windows_image

then start brltty inside the guest, this latter talking via USB with the
virtual device emulated by qemu:

brltty -b bm -d usb: -l debug -n -e > log 2>&1

Samuel

[Pete Batard]

Post by Samuel Thibault
Ah, no that's not the same kind of virtual device :) the vr driver in
brltty is for a TCP/IP-based virtual device. In my tests, I am running
windows inside qemu, and hotplugging the virtual braille device emulated
by qemu (usb_add braille from the qemu console).

I see. So that's a BrlAPI device. I should be able to get going using
the additional details you provided - thanks a lot.

Regards,

/Pete

[Samuel Thibault]

Post by Pete Batard

Post by Samuel Thibault
Ah, no that's not the same kind of virtual device :) the vr driver in
brltty is for a TCP/IP-based virtual device. In my tests, I am running
windows inside qemu, and hotplugging the virtual braille device emulated
by qemu (usb_add braille from the qemu console).

I see. So that's a BrlAPI device.

Err, depends where you look at in the chain :) The idea is this:

first | | QEMU | | second
brltty |--brlapi--| baum.c usb-serial.c |--USB--| brltty
-b xw | | | | -b bm

so it's a baum device emulated by qemu and rendered through brlapi by
the xw virtual device of brltty.

Samuel

[Tim Roberts]

Post by Samuel Thibault
so it's a baum device emulated by qemu and rendered through brlapi by
the xw virtual device of brltty.

Congratulations, you win the "most acronym-filled sentence of the week"
award...

[Pete Batard]

Just an update to let you know that I'm (very slowly) making my way into
trying to reproduce your issue.

I now have qemu with usb + virtual braille device support on Windows
(using the libusb-1.0 Windows backend for the qemu USB stack - might as
well have it on both ends), as well as a WinXP image with brltty+libusb 1.0.

Because I can't seem to have access to the Qemu console with the version
I compiled, be it GUI or network, I'm adding the braille device right
from the beginning rather than hotplugging, with -usbdevice braille
option to qemu. As a result my qemu + brltty startup script looks
something like:

brltty -b xw -x no -A auth=none,host=127.0.0.1:1
BRLAPI_HOST=127.0.0.1:1 qemu -k en-gb -usb -vnc 127.0.0.1:0 -hda
winxp.img -m 512 -localtime -net user -net nic,model=rtl8139 -usbdevice
braille

Now the WinXP virtual machine sees the device alright, and it is now
configured to use WinUSB as a driver.

However, I am currently getting an access error when running brltty in
the virtual image ("brltty -b bm -d usb: -l debug -n -e > brltty.log
2>&1") as shown in the log. Bit puzzling, as I have no problem reading
the strings off the device with the xusb test program for instance, and
open does not return an error there.

I should be able to sort things out, but this is taking a bit more time
than anticipated, so I just wanted to give a status update.

Regards,

/Pete

PS: while I get brltty to display something on the host, it only appears
for a few seconds ("BRLTTY 4.3dev" on a ~30x2 grid) and then disappears.
As the process still runs, I assume that the disappearance is normal.

[Samuel Thibault]

Post by Samuel Thibault
brltty -b xw -x no -A auth=none,host=127.0.0.1:1
BRLAPI_HOST=127.0.0.1:1 qemu -k en-gb -usb -vnc 127.0.0.1:0 -hda
winxp.img -m 512 -localtime -net user -net nic,model=rtl8139 -usbdevice
braille

BTW, to reproduce my issue, you need to enable smp support:

-smp 2

since without it I don't have any problem.

Samuel

[Pete Batard]

Post by Samuel Thibault
-smp 2

Yeah, I pretty much guessed so. It's just dreadfully slower when using
the smp option (at least 4x slower on my dual core machine - qemu only
seems to use one core for running all the CPUs/cores it emulates), so I
disabled it for the time being.

I'll enable it again when I'm in a position to test.

Regards,

/Pete

[Samuel Thibault]

Post by Pete Batard

Post by Samuel Thibault
-smp 2

Yeah, I pretty much guessed so. It's just dreadfully slower when using
the smp option

Ah, I guess there is no kvm acceleration on windows. In that case qemu
indeed only uses single-threaded emulation, as the memory coherency
requirements prevent any potential parallelization.

Post by Pete Batard
I'll enable it again when I'm in a position to test.

Ok.

Samuel

[Peter Stuge]

Post by Samuel Thibault

Post by Pete Batard

Post by Samuel Thibault
-smp 2

Yeah, I pretty much guessed so. It's just dreadfully slower when
using the smp option

Ah, I guess there is no kvm acceleration on windows. In that case
qemu indeed only uses single-threaded emulation,

That might mask the problem.


//Peter

[Samuel Thibault]

Post by Peter Stuge

Post by Samuel Thibault

Post by Pete Batard

Post by Samuel Thibault
-smp 2

Yeah, I pretty much guessed so. It's just dreadfully slower when
using the smp option

Ah, I guess there is no kvm acceleration on windows. In that case
qemu indeed only uses single-threaded emulation,

That might mask the problem.

Indeed, but apparently it doesn't, because qemu still interleaves the
emulation.

Samuel

[Pete Batard]

Hi Samuel,

Got a bit further. The issue I was having previously was linked to the
autoclaim libusb Windows backend feature now being disabled by default.
You're likely to face the same issue too if you use the latest source or
binary, and you're likely to have to modify your code to claim interface
0 before you do anything (like calling set_configuration) or turn
autoclaim back on in the source, as you will receive an error otherwise.

Unfortunately, while I'm getting further, I now get qemu to crash
altogether when running brltty, as the virtual braille device seems to
bring the whole program down on Windows.
I am able to see some debug messages onscreen in the virtual image but
because of buffering, the log never gets a chance to get written onto
the virtual disk, so I can't provide it.

I don't believe this is linked to my using the libusb 1.0 Windows
backend on host side, as I'm not seeing libusb related debug messages
there, and I would tend to think the brlapi virtual device from qemu
doesn't require the use of libusb on the host, as it's not attempting to
access physical USB devices.

This is the error I get on the host side from (with -l debug for brltty):

brltty.exe: Received Write request on fd 000001DC
brltty.exe: writing exception 9 to 000001DC
brltty.exe: !(wa->flags & BRLAPI_WF_CHARSET) not met: charset conversion
not supported (enable iconv?)
brltty.exe: exception 9 for packet type 119 on fd 000001DC
brltty.exe: Closing connection on fd 000001DC
BrlAPI exception: Operation not supported on Write request of size 151
(7e 00 00 00 00 00 00 01 00 00 00 28 00 00 00 28)
You may wish to add the -ldebug option to the brltty command line in
order to get additional information in the system log
brltty.exe:
This application has requested the Runtime to terminate it in an unusual
way.
Please contact the application's support team for more information.
Client on fd 000001DC did not give up control of tty 0x000104ca properly
brltty.exe: Releasing tty 0x000104ca
brltty.exe: freeing tty 0x000104ca

On the virtual image side, these are the brltty related operation that
seem to be occurring (copied from the crash screenshot, with the libusb
debug summarized):

brltty.exe: USB: Serial Number: 1
brltty.exe: probing with Baum protocol
brltty.exe: FTDI Request: 03 809C 0000
(successful libusb control transfer debug. Read data length is 0)
brltty.exe: FTDI Request: 02 0000 0000
(successful libusb control transfer debug. Read data length is 0)
brltty.exe: FTDI Request: 04 0008 0000 <- last message before crash

I'll probably give a try of my image in qemu on Linux when I get a
chance, but maybe you have a clue what the issue might be.

For information, I'm currently using the en_GB charset in qemu (-k
en-gb), but the same occurs when using the default en-us settings.

Regards,

/Pete

[Xiaofan Chen]

Post by Pete Batard
Got a bit further. The issue I was having previously was linked to the
autoclaim libusb Windows backend feature now being disabled by default.
You're likely to face the same issue too if you use the latest source or
binary, and you're likely to have to modify your code to claim interface
0 before you do anything (like calling set_configuration) or turn
autoclaim back on in the source, as you will receive an error otherwise.

Hmm, I thought that libusb_set_configuration() is not necessary
and libusb_claim_interface() is always necessary (if not
using autoclaim), right? I think this is consistent with Linux
libusb behavior.

The old version of libusb-win32 (up to 0.1.12.2) device driver need
usb_set_configuration(). But the next version of libusb-win32
should remove the need if the device is using the default
configuration (usually 1).

[Pete Batard]

Post by Xiaofan Chen
Hmm, I thought that libusb_set_configuration() is not necessary

Yes, it shouldn't be. Moreover, because of the Windows API limitations,
there's no guarantee set_configuration will work at all on Windows:

"from http://msdn.microsoft.com/en-us/library/ms793522.aspx: "The port
driver does not currently expose a service that allows higher-level
drivers to set the configuration."

Now, set_configuration is issued by the brltty code during
initialization, so I guess it's there more as a safety than anything else.

Post by Xiaofan Chen
and libusb_claim_interface() is always necessary (if not
using autoclaim), right?

Yes it is. Only problem with WinUSB is that what works on Linux (claim
interface 1 and start using it) does not work on Windows unless you
claim interface 0 first. This is one place where the libusb 1.0
behaviours on Windows and Linux will differ, i.e. where you cannot use
libusb 1.0 Linux code as is (unless autoclaim is set).

Regards,

/Pete

[Xiaofan Chen]

Post by Pete Batard

Post by Xiaofan Chen
and libusb_claim_interface() is always necessary (if not
using autoclaim), right?

Yes it is. Only problem with WinUSB is that what works on Linux (claim
interface 1 and start using it) does not work on Windows unless you
claim interface 0 first. This is one place where the libusb 1.0
behaviours on Windows and Linux will differ, i.e. where you cannot use
libusb 1.0 Linux code as is (unless autoclaim is set).

That is kind of strange. I think WinUSB can be used for
USB composite device. Say if Interface 0 is using the USB Mass
Storage Interface. Interface 1 is using WinUSB. How do you
claim Interface 0 from libusb-1.0 Windows backend then?
Presumably it will fail.

I do not remember WinUSB has such limitations last time
I tried it with Mike Zoran's USB Sound Steam Device
(USB Composite Device -- USB Audio + WinUSB). But the
host program is using native WinUSB API, not libusb.
His website is now down. But some information is here.
http://www.microchip.com/forums/fb.aspx?m=283861

[Pete Batard]

Post by Xiaofan Chen
That is kind of strange. I think WinUSB can be used for
USB composite device.

Ah but composite WinUSB devices are a whole different story.

As far as Windows is concerned (unless you fiddle with the composite
parent driver), a composite usb device is seen as a a set of independent
Windows devices, each with its own driver, and each with a single interface.

Thus, for composite devices, the problem of having to claim interface 0
never occurs, as any of the composite interface that uses WinUSB will be
seen as a standalone WinUSB device with only one interface (interface 0).

The WinUSB limitation only occurs for non composite devices with
multiple interfaces, which seems to be the case for the virtual braille
device. Either that, or there's a claim_interface missing somewhere in
the brltty code as the control request for set_configuration fails to
find a valid open interface to use (but then I'd expect the same code to
fail on Linux too).

Regards,

/Pete

[Xiaofan Chen]

Post by Pete Batard
The WinUSB limitation only occurs for non composite devices with
multiple interfaces, which seems to be the case for the virtual braille
device. Either that, or there's a claim_interface missing somewhere in
the brltty code as the control request for set_configuration fails to
find a valid open interface to use (but then I'd expect the same code to
fail on Linux too).

By definition, "A device that has multiple interfaces controlled
independently of each other is referred to as a composite device."
http://www.cygnal.org/ubb/Forum9/HTML/001050.html

Unless it is like the CDC device where the two interfaces
are not independently controlled. In that case, probably
two interfaces need to be claimed at the same time.

But according to the codes, the brltty usb-serial device
is not a device with multiple interfaces. According to
Samuel, he is using the following USB descriptors
(to emulate a FT232BM vendor specific device actually).

Maybe I am missing something here...

qemu-0.12.4\hw\usb-serial.c

static const uint8_t qemu_serial_dev_descriptor[] = {
0x12, /* u8 bLength; */
0x01, /* u8 bDescriptorType; Device */
0x00, 0x02, /* u16 bcdUSB; v2.0 */

0x00, /* u8 bDeviceClass; */
0x00, /* u8 bDeviceSubClass; */
0x00, /* u8 bDeviceProtocol; [ low/full speeds only ] */
0x08, /* u8 bMaxPacketSize0; 8 Bytes */

/* Vendor and product id are arbitrary. */
0x03, 0x04, /* u16 idVendor; */
0x00, 0xFF, /* u16 idProduct; */
0x00, 0x04, /* u16 bcdDevice */

0x01, /* u8 iManufacturer; */
0x02, /* u8 iProduct; */
0x03, /* u8 iSerialNumber; */
0x01 /* u8 bNumConfigurations; */
};

static const uint8_t qemu_serial_config_descriptor[] = {

/* one configuration */
0x09, /* u8 bLength; */
0x02, /* u8 bDescriptorType; Configuration */
0x20, 0x00, /* u16 wTotalLength; */
0x01, /* u8 bNumInterfaces; (1) */
0x01, /* u8 bConfigurationValue; */
0x00, /* u8 iConfiguration; */
0x80, /* u8 bmAttributes;
Bit 7: must be set,
6: Self-powered,
5: Remote wakeup,
4..0: resvd */
100/2, /* u8 MaxPower; */

/* one interface */
0x09, /* u8 if_bLength; */
0x04, /* u8 if_bDescriptorType; Interface */
0x00, /* u8 if_bInterfaceNumber; */
0x00, /* u8 if_bAlternateSetting; */
0x02, /* u8 if_bNumEndpoints; */
0xff, /* u8 if_bInterfaceClass; Vendor Specific */
0xff, /* u8 if_bInterfaceSubClass; Vendor Specific */
0xff, /* u8 if_bInterfaceProtocol; Vendor Specific */
0x02, /* u8 if_iInterface; */

/* Bulk-In endpoint */
0x07, /* u8 ep_bLength; */
0x05, /* u8 ep_bDescriptorType; Endpoint */
0x81, /* u8 ep_bEndpointAddress; IN Endpoint 1 */
0x02, /* u8 ep_bmAttributes; Bulk */
0x40, 0x00, /* u16 ep_wMaxPacketSize; */
0x00, /* u8 ep_bInterval; */

/* Bulk-Out endpoint */
0x07, /* u8 ep_bLength; */
0x05, /* u8 ep_bDescriptorType; Endpoint */
0x02, /* u8 ep_bEndpointAddress; OUT Endpoint 2 */
0x02, /* u8 ep_bmAttributes; Bulk */
0x40, 0x00, /* u16 ep_wMaxPacketSize; */
0x00 /* u8 ep_bInterval; */
};

[Pete Batard]

Post by Xiaofan Chen
By definition, "A device that has multiple interfaces controlled
independently of each other is referred to as a composite device."
http://www.cygnal.org/ubb/Forum9/HTML/001050.html

I must admit I've never been clear as to how one differentiate a
composite device from a non composite device with multiple interfaces. I
looked at Wikipedia and other sources, and the "controlled
independently" part is very ambiguous without an actual example. What
does "controlled independently" actually mean in practice?

Now, I've seen people using the WinUsb_GetAssociatedInterface API call,
and I've even implemented it in my code to address the switching of
interfaces for non composite WinUSB devices, so there are definitely
provisions for non composite multi-interface devices in WinUSB.

Post by Xiaofan Chen
But according to the codes, the brltty usb-serial device
is not a device with multiple interfaces.

Well, it's definitely not seen as a composite device in XP, and I'm not
seeing any "claimed interface X" debug message in the libusb output, so
I'm starting to think there's a claim_interface missing in their code.
Or can control requests be issued on Linux without first claiming an
interface?

Wasn't really planning to push this matter further, since autoclaim
sorts the issue as far as I'm concerned, and there's still the problem
of qemu crashing and troubleshooting the actual reported issue to
address, but I'll see what I can do later on.

Regards,

/Pete

[Xiaofan Chen]

Post by Pete Batard

Post by Xiaofan Chen
By definition, "A device that has multiple interfaces controlled
independently of each other is referred to as a composite device."
http://www.cygnal.org/ubb/Forum9/HTML/001050.html

I must admit I've never been clear as to how one differentiate a
composite device from a non composite device with multiple interfaces. I
looked at Wikipedia and other sources, and the "controlled
independently" part is very ambiguous without an actual example. What
does "controlled independently" actually mean in practice?

For example, the CDC-ACM device has the data interface (Bulk IN/Out)
and the notification interface (Interrupt-In), they are not independently
controlled, so normally they are not referred as USB Composite device.

And typical USB Audio device has multiple associated interface.
Therefore they are also not considered as USB composite device.

Post by Pete Batard
Now, I've seen people using the WinUsb_GetAssociatedInterface API call,
and I've even implemented it in my code to address the switching of
interfaces for non composite WinUSB devices, so there are definitely
provisions for non composite multi-interface devices in WinUSB.

That makes sense.

Post by Pete Batard

Post by Xiaofan Chen
But according to the codes, the brltty usb-serial device
is not a device with multiple interfaces.

Well, it's definitely not seen as a composite device in XP, and I'm not
seeing any "claimed interface X" debug message in the libusb output, so
I'm starting to think there's a claim_interface missing in their code.
Or can control requests be issued on Linux without first claiming an
interface?

I vaguely remember some control requests can be done this way
under Linux but I have never used this.

[Samuel Thibault]

Hello,

Post by Pete Batard
I don't believe this is linked to my using the libusb 1.0 Windows
backend on host side, as I'm not seeing libusb related debug messages
there, and I would tend to think the brlapi virtual device from qemu
doesn't require the use of libusb on the host, as it's not attempting to
access physical USB devices.

Yes.

Post by Pete Batard
brltty.exe: !(wa->flags & BRLAPI_WF_CHARSET) not met: charset conversion
not supported (enable iconv?)

That's a bad interaction between brltty being built without support for
converting charsets and qemu not coping so well with that issue. Are you
rebuilding brltty yourself? For the host part, you could just use the
pre-built binary from http://brl.thefreecat.org/brltty/brltty-win-4.2-1.zip
which has support for charset conversion.

Post by Pete Batard
For information, I'm currently using the en_GB charset in qemu (-k
en-gb), but the same occurs when using the default en-us settings.

The keyboard configuration is independant from the charset being set by
qemu (always assumed to be latin1).

Samuel

[Pete Batard]

Are you rebuilding brltty yourself?

Yes, as I'm trying to use libusb-1.0 on both ends, and it's not
available by default with brltty/MinGW

For the host part, you could just use the
pre-built binary from http://brl.thefreecat.org/brltty/brltty-win-4.2-1.zip
which has support for charset conversion.

OK, I guess I'll try that later on, and see how it goes. Or I'll just
try to add iconv to MinGW, as this seems to be the part that's missing.

The weird thing is that I currently get a report of "iconv: yes" in the
brltty configuration summary, eventhough configure reports:

checking iconv.h usability... no
checking iconv.h presence... no
checking for iconv.h... no

Regards,

/Pete

[Samuel Thibault]

Post by Pete Batard

Are you rebuilding brltty yourself?

Yes, as I'm trying to use libusb-1.0 on both ends, and it's not
available by default with brltty/MinGW

Yes, but as you guessed, for the host part you do not need any usb
stuff.

Post by Pete Batard

For the host part, you could just use the
pre-built binary from http://brl.thefreecat.org/brltty/brltty-win-4.2-1.zip
which has support for charset conversion.

OK, I guess I'll try that later on, and see how it goes. Or I'll just
try to add iconv to MinGW, as this seems to be the part that's missing.

Yes.

Post by Pete Batard
The weird thing is that I currently get a report of "iconv: yes" in the
checking iconv.h usability... no
checking iconv.h presence... no
checking for iconv.h... no

IIRC that's a bug in the configuration summary.

Samuel

[Xiaofan Chen]

On Thu, May 20, 2010 at 9:57 PM, Samuel Thibault

Post by Samuel Thibault

Post by Pete Batard

Are you rebuilding brltty yourself?

Yes, as I'm trying to use libusb-1.0 on both ends, and it's not
available by default with brltty/MinGW

Yes, but as you guessed, for the host part you do not need any usb
stuff.

Sorry I am a bit slow here as well since I have not tried to use brltty myself.
But if you are using FT232BM emulation, you will use the FTDI
driver on the host and they emulate a serial port. Right? In that
case, the host will not need to use libusb at all. Unless the host
is using libftdi which uses the libusb.

Where is libusb in the picture here ( for Windows host
and the virtual device on the virtual qemu Windows image)?

Sorry again if I am asking a stupid question...

[Pete Batard]

Post by Xiaofan Chen
Where is libusb in the picture here ( for Windows host
and the virtual device on the virtual qemu Windows image)?

OK, from where I stand, even if libusb is not used by the emulated
braille device from qemu, as qemu uses brlAPI for this emulation, and
brlAPI requires USB support at compilation time, I had to add libusb to
compile brltty, which in turn allowed me to compile qemu with the
braille virtual device.

So the only requirement on the hostside seems to be for compilation, and
not runtime.

On the virtual image side then, the virtual braille device is seen as a
regular USB peripheral, so there we have the usual compilation+runtime
libusb dependency.

By the way, I just recompiled qemu with libiconv support, and I'm no
longer observing any crashes. Currently trying to run the test with -smp
enabled...

Regards,

/Pete

[Pete Batard]

Hi Samuel,

Here's some long awaited update on the issue.

As indicated previously, I am now able to test with the brltty virtual
device in qemu, and, while I'm not able to reproduce the smp issue on
Windows (possibly because my emulation with -smp is too slow), I have
observed the alleged extra bytes with and without -smp, so this is what
I have been focused on troubleshooting lately.

Now, I say "alleged", because the tests I have run with dumping the data
received from WinUSB as well as sniffing the USB traffic with SnoopyPro
seem to indicate that, whatever the problem is, libusb is just providing
the data it receives from the (virtual) device, as can be shown in the
screenshot below:
Loading Image...

Both the hex dump and SnoopyPro indicate that the extra 0xB1 0x00 bytes
are from the transfer itself, and not something that's added down the
line. Possibly, these could be remnant of a previous bulk transfer if
the requested data length was too small, but but we normally detect (and
flag) overflows, so that would only work if the virtual device is
buffering the data or something.

At any rate, you probably want to have a look at the output from the
virtual device using a USB sniffer as well as check whether brltty is
requesting the right amount of data, because I'm not seeing any evidence
that libusb is doing anything wrong there.

As to the smp issue, I'm more ready to believe that there might be a
libusb bug there, so I'll see what I can do to try to reproduce the
problem on a Linux host. Again, it might be a while before I get back to
you on that.

Regards,

/Pete

PS: If you want to see a *very crude* binary dump of the data transfers
from libusb (will dump the whole data buffer, not just the transferred
data), you can add the following function in libusb/os/windows_usb.c:

void display_buffer_hex(unsigned char *buffer, unsigned size)
{
unsigned i;
char line[256];
char splouf[5];

line[0] = 0;
for (i=0; i<size; i++) {
if ((!(i%0x10)) && (i != 0)) {
usbi_dbg("%s", line);
line[0] = 0;
}
sprintf(splouf, " %02X", buffer[i]);
strcat(line, splouf);
}
usbi_dbg("%s", line);
}

Then you can modify winusb_copy_transfer_data to add the following
before "return LIBUSB_TRANSFER_COMPLETED;"

usbi_dbg("buff (io_size): %p (%d)", transfer->buffer, transfer->length);
display_buffer_hex(transfer->buffer, transfer->length);

[Peter Stuge]

have a look at the output from the virtual device

Good advice. Maybe hack some debug prints into qemu.


//Peter

[Xiaofan Chen]

Post by Pete Batard
Both the hex dump and SnoopyPro indicate that the extra 0xB1 0x00 bytes
are from the transfer itself, and not something that's added down the
line. Possibly, these could be remnant of a previous bulk transfer if
the requested data length was too small, but but we normally detect (and
flag) overflows, so that would only work if the virtual device is
buffering the data or something.

The extra two bytes are normal. It is the FTDI device modem
status bytes.

It has been discussed before.
http://old.nabble.com/Any-FTDI-245-experts-here--td28362404.html#a28362404

As Samuel mentioned before, the virtual device emulated
an FT232BM device.

[Samuel Thibault]

Post by Xiaofan Chen

Post by Pete Batard
Both the hex dump and SnoopyPro indicate that the extra 0xB1 0x00 bytes
are from the transfer itself, and not something that's added down the
line. Possibly, these could be remnant of a previous bulk transfer if
the requested data length was too small, but but we normally detect (and
flag) overflows, so that would only work if the virtual device is
buffering the data or something.

The extra two bytes are normal. It is the FTDI device modem
status bytes.

Yes. Apparently Pete missed the mail in which I told about it: what
seems to happen is that because of issues with libusb, brltty doesn't
manage to find out that it's an ftdi device and thus doesn't enable its
ftdi filter.

Samuel

[Pete Batard]

Post by Samuel Thibault

Post by Xiaofan Chen
The extra two bytes are normal. It is the FTDI device modem
status bytes.

Yes. Apparently Pete missed the mail in which I told about it: what
seems to happen is that because of issues with libusb, brltty doesn't
manage to find out that it's an ftdi device and thus doesn't enable its
ftdi filter.

Ah, OK. Now that you mention it, I saw the FTDI discussion but I
completely missed the fact that it was about the extra bytes. Didn't
hurt to run a check on my end to try to figure out if there was extra
data added by libusb anyway.

Regards,

/Pete

[Samuel Thibault]

Post by Xiaofan Chen

Post by Samuel Thibault
Yes, but as you guessed, for the host part you do not need any usb
stuff.

Sorry I am a bit slow here as well since I have not tried to use brltty myself.
But if you are using FT232BM emulation, you will use the FTDI
driver on the host and they emulate a serial port. Right?

That part happens in qemu only, not in the brltty process running on the
host.

Post by Xiaofan Chen
In that case, the host will not need to use libusb at all.

Yes.

Post by Xiaofan Chen
Unless the host is using libftdi which uses the libusb.

qemu has its own ftdi implementation.

Post by Xiaofan Chen
Where is libusb in the picture here ( for Windows host
and the virtual device on the virtual qemu Windows image)?

In the brltty running in the Windows running in the virtual machine.

Samuel

[Pete Batard]

OK, finally managed to run the long awaited test on Linux, but I still
don't seem to be able to reproduce the issue.

I'm running 'brltty -b bm usb: -l debug -n -e > brltty.log 2>&1' inside
the virtual machine and feeding the log to baretail to see if there's
any sign of a 60 secs libusb freezout, but I'm still not seeing
anything. The virtual image is running with -smp 2.

I'm attaching the zipped log I got in case I'm missing something.

Note that I pressed a few keys on the host brltty device, which you
should see in the log, to ensure that both brltty's appeared to
communicate properly.

My emulation is still very slow though (but a lot more usable than the
Windows one with -smp). I added KVM to my kernel, and recompiled qemu
with the kvm option, yet even on a fairly recent quad core machine, I'm
not seeing much benefit. Some of the slowdown (screen refreshes) might
also be due to using an X11 client to access the Linux server.

Anyway, I'll see what I can do next. Maybe I'll try one of the Qemu
accelerators to see if it improves things. Are you using one yourself,
or are you just using KVM? Or maybe you didn't recompile Qemu but used a
binary version. If so, can you tell me which one?

If I had a Qemu image that ran fast enough, I think I'd be more
confident on whether this last test I ran is significant or not.

Regards,

/Pete

[Samuel Thibault]

Post by Pete Batard
OK, finally managed to run the long awaited test on Linux, but I still
don't seem to be able to reproduce the issue.

Err, just to make sure it's clear: we do have tested it on Linux without
any problem.

Post by Pete Batard
I added KVM to my kernel, and recompiled qemu with the kvm option,
yet even on a fairly recent quad core machine, I'm not seeing much
benefit.

That's odd. You can lsof -p $(pidof qemu) to check that it's really
using /dev/kvm.

Post by Pete Batard
or are you just using KVM?

I'm using KVM, using the debian-provided binaries.

Samuel

[Pete Batard]

Post by Samuel Thibault
Err, just to make sure it's clear: we do have tested it on Linux without
any problem.

I mean, a Linux Qemu host. I was using a Windows Qemu host previously,
which was way too slow. The virtual image on both hosts is still Windows XP.

Post by Samuel Thibault
That's odd. You can lsof -p $(pidof qemu) to check that it's really
using /dev/kvm.

You're right, I'm not seeing any mention of kvm there. I'm 100% sure KVM
is available though, since it's now native in my kernel (not a module),
and of course I double checked I was using my newly compiled kernel. The
summary of qemu config also stated that kvm was enabled for compilation.
I guess I'll try to pick some precompiled binaries to see if it works
better.

Regards,

/ete

[Samuel Thibault]

Post by Pete Batard

Post by Samuel Thibault
Err, just to make sure it's clear: we do have tested it on Linux without
any problem.

I mean, a Linux Qemu host.

Ah, ok.

Post by Pete Batard

Post by Samuel Thibault
That's odd. You can lsof -p $(pidof qemu) to check that it's really
using /dev/kvm.

You're right, I'm not seeing any mention of kvm there. I'm 100% sure KVM
is available though, since it's now native in my kernel (not a module),

Do you have permissions on the /dev/kvm node?

Samuel

[Pete Batard]

Post by Samuel Thibault
Do you have permissions on the /dev/kvm node?

Was running as root so yes, but I found my stupid mistake since then:
It's not because one adds --enable-kvm during config that kvm is used by
default. You also need to add --enable-kvm when launching qemu and, of
course, I wasn't doing that.

But with that option, I got the new error: "No SMP KVM support, use
'-smp 1'".

The weird thing is, SMP KVM support seems to have been fixed recently in
the staging qemu git tree, and that fix hasn't made its way into the
0.12 stable branch yet
(http://git.qemu.org/qemu.git/commit/?id=7ac9f9be20b95e3963f0404fa6c5c5c9654106de).
Does debian use a different version that official that supports
--enable-kvm with -smp 2?

Now, I have recompiled a version of qemu from the latest git, and I am
able to run it with both --enable-kvm and -smp 2 at last... but it's
about as dreadfully slow as when I try -smp 2 on Windows (if not worse),
despite the fact that kvm is definitely used. With kvm enabled, the
image is virtually unusable for testing, be it through X11 or VNC.

I guess the one test that matters then is the one I ran without
--enable-kvm, and from a compiled version of the official 0.12.3, I
haven't been able to see anything.

If possible, can you give a try to the official 0.12.3 (or 0.12.4) and
let us know if you still see the issue there?

Regards,

/Pete

[Xiaofan Chen]

On Fri, May 7, 2010 at 8:10 AM, Samuel Thibault

Post by Samuel Thibault
Hello,
the timeout parameter is set to 20, but the call blocks until I press a
key on the device. This happens both on cygwin and on mingw. I'm using
git bd62c472.

What is commit bd62c472? It does not seem to like recent version.
Please try the latest version. Your behavior may be because in the
old version, it is not using USE_HIDD_FOR_REPORTS.

And 20ms is normally too short a value for timeout.

[Samuel Thibault]

Post by Xiaofan Chen
What is commit bd62c472? It does not seem to like recent version.

This is

commit bd62c472c4dfec5640f12662f1b01bd3ef41d1f4
Author: Michael Plante <***@gmail.com>
Date: Sat Apr 24 11:19:51 2010 +0100

[INTERNAL - NOT FOR RELEASE] updated generated rc file for 1.0.7

Post by Xiaofan Chen
Please try the latest version. Your behavior may be because in the
old version, it is not using USE_HIDD_FOR_REPORTS.

It is.

The only difference I can see with the current head of the pbatard
branch is the autoclaim part.

Samuel

[Xiaofan Chen]

On Fri, May 7, 2010 at 4:01 PM, Samuel Thibault

Post by Samuel Thibault
This is
commit bd62c472c4dfec5640f12662f1b01bd3ef41d1f4
Date:   Sat Apr 24 11:19:51 2010 +0100
   [INTERNAL - NOT FOR RELEASE] updated generated rc file for 1.0.7

Post by Xiaofan Chen
Please try the latest version. Your behavior may be because in the
old version, it is not using USE_HIDD_FOR_REPORTS.

It is.
The only difference I can see with the current head of the pbatard
branch is the autoclaim part.

I see. Please post the descriptor as well. If you have Linux, please
use "lsusb -vvv". If you have Windows, please try usbview. If you
have the access to the firmware, then it is even better.

If you have access to Linux, verify your application works under
Linux first.

Also please still update to the latest git. If your device is a USB
composite device with a keyboard interface, it may be helped
by this commit.
http://git.libusb.org/?p=libusb-pbatard.git;a=commit;h=a2b1e378243db96eb73f4526aade381b99b21db4

[Xiaofan Chen]

On Fri, May 7, 2010 at 4:26 PM, Samuel Thibault

Post by Xiaofan Chen
I see. Please post the descriptor as well. If you have Linux, please
use "lsusb -vvv". If you have Windows, please try usbview. If you
have the access to the firmware, then it is even better.

Well, actually it's qemu/hw/usb-serial.c :) which emulates a standard
FTDI 0304 USB serial chip.

Post by Xiaofan Chen
If you have access to Linux, verify your application works under
Linux first.

It works with Linux, and with libusb-win32 1.1.12.2 on windows.

Post by Xiaofan Chen
Also please still update to the latest git. If your device is a USB
composite device with a keyboard interface, it may be helped
by this commit.

It is not composite, it's just a standard serial port with a braille
display behind.

I see. So it is not an HID device and this has nothing to do with
the HID backend.

Did you install the WinUSB device driver for you device? Does
Windows recognize it as a WinUSB device?

Could you post your host code?

[Samuel Thibault]

Post by Xiaofan Chen
Did you install the WinUSB device driver for you device? Does
Windows recognize it as a WinUSB device?

Yes, the whole thing is almost working: when the device sends data,
brltty receives it, and when brltty sends data, the devices shows it.
But when the device doesn't send data, brltty is stalled in
libusb_bulk_transfer.

Post by Xiaofan Chen
Could you post your host code?

It is available on

svn checkout svn://mielke.cc/main/brltty

in Programs/usb_libusb-1.0.c. The call trace is

readUsbBytes() Drivers/Braille/Baum/braille.c:2524
usbReapInput() Programs/usb.c:829
usbAwaitInput() Programs/usb.c:760
usbReadEndpoint() Programs/usb_libusb-1.0.c:290
libusb_bulk_transfer()

Samuel

/*
* BRLTTY - A background process providing access to the console screen (when in
* text mode) for a blind person using a refreshable braille display.
*
* Copyright (C) 1995-2010 by The BRLTTY Developers.
*
* BRLTTY comes with ABSOLUTELY NO WARRANTY.
*
* This is free software, placed under the terms of the
* GNU General Public License, as published by the Free Software
* Foundation; either version 2 of the License, or (at your option) any
* later version. Please see the file LICENSE-GPL for details.
*
* Web Page: http://mielke.cc/brltty/
*
* This software is maintained by Dave Mielke <***@mielke.cc>.
*/

#include "prologue.h"

#include <string.h>
#include <errno.h>
#include <libusb.h>

#include "log.h"
#include "io_usb.h"
#include "usb_internal.h"

struct UsbDeviceExtensionStruct {
libusb_device *device;
libusb_device_handle *handle;
};

static libusb_context *usbContext = NULL;
static libusb_device **usbDeviceList = NULL;
static int usbDeviceCount = 0;

static int
usbToErrno (enum libusb_error error) {
switch (error) {
case LIBUSB_ERROR_IO:
return EIO;

case LIBUSB_ERROR_INVALID_PARAM:
return EINVAL;

case LIBUSB_ERROR_ACCESS:
return EACCES;

case LIBUSB_ERROR_NO_DEVICE:
return ENODEV;

case LIBUSB_ERROR_NOT_FOUND:
return ENOENT;

case LIBUSB_ERROR_BUSY:
return EBUSY;

case LIBUSB_ERROR_TIMEOUT:
return EAGAIN;

#ifdef EMSGSIZE
case LIBUSB_ERROR_OVERFLOW:
return EMSGSIZE;
#endif /* EMSGSIZE */

case LIBUSB_ERROR_PIPE:
return EPIPE;

case LIBUSB_ERROR_INTERRUPTED:
return EINTR;

case LIBUSB_ERROR_NO_MEM:
return ENOMEM;

case LIBUSB_ERROR_NOT_SUPPORTED:
return ENOSYS;

default:
LogPrint(LOG_DEBUG, "unsupported libusb1 error code: %d", error);
case LIBUSB_ERROR_OTHER:
return EIO;
}
}

static void
usbSetErrno (enum libusb_error error, const char *action) {
errno = usbToErrno(error);
if (action) LogError(action);
}

static int
usbGetHandle (UsbDeviceExtension *devx) {
if (!devx->handle) {
int result;

if ((result = libusb_open(devx->device, &devx->handle)) != LIBUSB_SUCCESS) {
usbSetErrno(result, "libusb_open");
return 0;
}
}

return 1;
}

int
usbResetDevice (UsbDevice *device) {
UsbDeviceExtension *devx = device->extension;

if (usbGetHandle(devx)) {
int result = libusb_reset_device(devx->handle);
if (result == LIBUSB_SUCCESS) return 1;
usbSetErrno(result, "libusb_reset_device");
}

return 0;
}

int
usbDisableAutosuspend (UsbDevice *device) {
errno = ENOSYS;
LogError("USB device autosuspend disable");
return 0;
}

int
usbSetConfiguration (
UsbDevice *device,
unsigned char configuration
) {
UsbDeviceExtension *devx = device->extension;

if (usbGetHandle(devx)) {
int result = libusb_set_configuration(devx->handle, configuration);
if (result == LIBUSB_SUCCESS) return 1;
usbSetErrno(result, "libusb_set_configuration");
}

return 0;
}

int
usbClaimInterface (
UsbDevice *device,
unsigned char interface
) {
UsbDeviceExtension *devx = device->extension;

if (usbGetHandle(devx)) {
int result = libusb_claim_interface(devx->handle, interface);
if (result == LIBUSB_SUCCESS) return 1;
usbSetErrno(result, "libusb_claim_interface");
}

return 0;
}

int
usbReleaseInterface (
UsbDevice *device,
unsigned char interface
) {
UsbDeviceExtension *devx = device->extension;

if (usbGetHandle(devx)) {
int result = libusb_release_interface(devx->handle, interface);
if (result == LIBUSB_SUCCESS) return 1;
usbSetErrno(result, "libusb_release_interface");
}

return 0;
}

int
usbSetAlternative (
UsbDevice *device,
unsigned char interface,
unsigned char alternative
) {
UsbDeviceExtension *devx = device->extension;

if (usbGetHandle(devx)) {
int result = libusb_set_interface_alt_setting(devx->handle, interface, alternative);
if (result == LIBUSB_SUCCESS) return 1;
usbSetErrno(result, "libusb_set_interface_alt_setting");
}

return 0;
}

int
usbClearEndpoint (
UsbDevice *device,
unsigned char endpointAddress
) {
UsbDeviceExtension *devx = device->extension;

if (usbGetHandle(devx)) {
int result = libusb_clear_halt(devx->handle, endpointAddress);
if (result == LIBUSB_SUCCESS) return 1;
usbSetErrno(result, "libusb_clear_halt");
}

return 0;
}

int
usbControlTransfer (
UsbDevice *device,
unsigned char direction,
unsigned char recipient,
unsigned char type,
unsigned char request,
unsigned short value,
unsigned short index,
void *buffer,
int length,
int timeout
) {
UsbDeviceExtension *devx = device->extension;

if (usbGetHandle(devx)) {
int result = libusb_control_transfer(devx->handle,
direction | recipient | type,
request, value, index,
buffer, length, timeout);
if (result >= 0) return result;
usbSetErrno(result, "");
}

return -1;
}

void *
usbSubmitRequest (
UsbDevice *device,
unsigned char endpointAddress,
void *buffer,
int length,
void *context
) {
errno = ENOSYS;
LogError("USB request submit");
return NULL;
}

int
usbCancelRequest (
UsbDevice *device,
void *request
) {
errno = ENOSYS;
LogError("USB request cancel");
return 0;
}

void *
usbReapResponse (
UsbDevice *device,
unsigned char endpointAddress,
UsbResponse *response,
int wait
) {
errno = ENOSYS;
LogError("USB request reap");
return NULL;
}

int
usbReadEndpoint (
UsbDevice *device,
unsigned char endpointNumber,
void *buffer,
int length,
int timeout
) {
UsbDeviceExtension *devx = device->extension;

if (usbGetHandle(devx)) {
const UsbEndpoint *endpoint;

if ((endpoint = usbGetInputEndpoint(device, endpointNumber))) {
const UsbEndpointDescriptor *descriptor = endpoint->descriptor;
UsbEndpointTransfer transfer = USB_ENDPOINT_TRANSFER(descriptor);
int actual_length;
int result;

switch (transfer) {
case UsbEndpointTransfer_Bulk:
result = libusb_bulk_transfer(devx->handle, descriptor->bEndpointAddress,
buffer, length, &actual_length, timeout);
break;

case UsbEndpointTransfer_Interrupt:
result = libusb_interrupt_transfer(devx->handle, descriptor->bEndpointAddress,
buffer, length, &actual_length, timeout);
break;

default:
LogPrint(LOG_ERR, "USB endpoint input transfer not supported: 0X%02X", transfer);
result = LIBUSB_ERROR_NOT_SUPPORTED;
break;
}

if (result == LIBUSB_SUCCESS) {
if (!usbApplyInputFilters(device, buffer, length, &result)) {
result = LIBUSB_ERROR_IO;
}
}

if (result == LIBUSB_SUCCESS) return actual_length;
usbSetErrno(result, NULL);
}
}

if (errno != EAGAIN) LogError("USB endpoint read");
return -1;
}

int
usbWriteEndpoint (
UsbDevice *device,
unsigned char endpointNumber,
const void *buffer,
int length,
int timeout
) {
UsbDeviceExtension *devx = device->extension;

if (usbGetHandle(devx)) {
const UsbEndpoint *endpoint;

if ((endpoint = usbGetOutputEndpoint(device, endpointNumber))) {
const UsbEndpointDescriptor *descriptor = endpoint->descriptor;
UsbEndpointTransfer transfer = USB_ENDPOINT_TRANSFER(descriptor);
int actual_length;
int result;

switch (transfer) {
case UsbEndpointTransfer_Bulk:
result = libusb_bulk_transfer(devx->handle, descriptor->bEndpointAddress,
(void *)buffer, length, &actual_length, timeout);
break;

case UsbEndpointTransfer_Interrupt:
result = libusb_interrupt_transfer(devx->handle, descriptor->bEndpointAddress,
(void *)buffer, length, &actual_length, timeout);
break;

default:
LogPrint(LOG_ERR, "USB endpoint output transfer not supported: 0X%02X", transfer);
result = LIBUSB_ERROR_NOT_SUPPORTED;
break;
}

if (result == LIBUSB_SUCCESS) return actual_length;
usbSetErrno(result, NULL);
}
}

LogError("USB endpoint write");
return -1;
}

int
usbReadDeviceDescriptor (UsbDevice *device) {
UsbDeviceExtension *devx = device->extension;
struct libusb_device_descriptor descriptor;
int result;

if ((result = libusb_get_device_descriptor(devx->device, &descriptor)) == LIBUSB_SUCCESS) {
memcpy(&device->descriptor, &descriptor, UsbDescriptorSize_Device);
return 1;
} else {
usbSetErrno(result, "libusb_get_device_descriptor");
}

return 0;
}

int
usbAllocateEndpointExtension (UsbEndpoint *endpoint) {
return 1;
}

void
usbDeallocateEndpointExtension (UsbEndpointExtension *eptx) {
}

void
usbDeallocateDeviceExtension (UsbDeviceExtension *devx) {
if (devx->handle) libusb_close(devx->handle);
libusb_unref_device(devx->device);
free(devx);
}

UsbDevice *
usbFindDevice (UsbDeviceChooser chooser, void *data) {
int result;
UsbDeviceExtension *devx;

if (!usbContext) {
if ((result = libusb_init(&usbContext)) != LIBUSB_SUCCESS) {
usbSetErrno(result, "libusb_init");
return NULL;
}
}

if (!usbDeviceList) {
ssize_t count;

if ((count = libusb_get_device_list(usbContext, &usbDeviceList)) < 0) {
usbSetErrno(count, "libusb_get_device_list");
return NULL;
}

usbDeviceCount = count;
}

if ((devx = malloc(sizeof(*devx)))) {
libusb_device **libusbDevice = usbDeviceList;
int deviceCount = usbDeviceCount;

while (deviceCount) {
deviceCount -= 1;
devx->device = *libusbDevice++;
libusb_ref_device(devx->device);

devx->handle = NULL;

{
UsbDevice *device = usbTestDevice(devx, chooser, data);
if (device) return device;
}

libusb_unref_device(devx->device);
}

free(devx);
} else {
LogError("malloc");
}

return NULL;
}

void
usbForgetDevices (void) {
if (usbDeviceList) {
libusb_free_device_list(usbDeviceList, 1);
usbDeviceList = NULL;
}

usbDeviceCount = 0;
}

[Xiaofan Chen]

On Fri, May 7, 2010 at 4:43 PM, Samuel Thibault

Post by Samuel Thibault

Post by Xiaofan Chen
Did you install the WinUSB device driver for you device? Does
Windows recognize it as a WinUSB device?

Yes, the whole thing is almost working: when the device sends data,
brltty receives it, and when brltty sends data, the devices shows it.
But when the device doesn't send data, brltty is stalled in
libusb_bulk_transfer.

Post by Xiaofan Chen
Could you post your host code?

It is available on
svn checkout svn://mielke.cc/main/brltty
in Programs/usb_libusb-1.0.c. The call trace is
 readUsbBytes() Drivers/Braille/Baum/braille.c:2524
 usbReapInput() Programs/usb.c:829
 usbAwaitInput() Programs/usb.c:760
 usbReadEndpoint() Programs/usb_libusb-1.0.c:290
 libusb_bulk_transfer()

Thanks a lot. Please post the debug log as pointed by Pete.

BTW, I think the libusb-1.0 code in Britty is half baked. It is now basically
similar to the libusb-0.1 code and does not use the facility of
libusb-1.0 provides -- namely the asynchronous API. It should be
able to have similar functionality of usb_linux.c (which uses sysfs).

[Samuel Thibault]

Post by Xiaofan Chen
I see. Please post the descriptor as well. If you have Linux, please
use "lsusb -vvv". If you have Windows, please try usbview. If you
have the access to the firmware, then it is even better.

Well, actually it's qemu/hw/usb-serial.c :) which emulates a standard
FTDI 0304 USB serial chip.

static const uint8_t qemu_serial_dev_descriptor[] = {
0x12, /* u8 bLength; */
0x01, /* u8 bDescriptorType; Device */
0x00, 0x02, /* u16 bcdUSB; v2.0 */

0x00, /* u8 bDeviceClass; */
0x00, /* u8 bDeviceSubClass; */
0x00, /* u8 bDeviceProtocol; [ low/full speeds only ] */
0x08, /* u8 bMaxPacketSize0; 8 Bytes */

/* Vendor and product id are arbitrary. */
0x03, 0x04, /* u16 idVendor; */
0x00, 0xFF, /* u16 idProduct; */
0x00, 0x04, /* u16 bcdDevice */

0x01, /* u8 iManufacturer; */
0x02, /* u8 iProduct; */
0x03, /* u8 iSerialNumber; */
0x01 /* u8 bNumConfigurations; */
};

static const uint8_t qemu_serial_config_descriptor[] = {

/* one configuration */
0x09, /* u8 bLength; */
0x02, /* u8 bDescriptorType; Configuration */
0x20, 0x00, /* u16 wTotalLength; */
0x01, /* u8 bNumInterfaces; (1) */
0x01, /* u8 bConfigurationValue; */
0x00, /* u8 iConfiguration; */
0x80, /* u8 bmAttributes;
Bit 7: must be set,
6: Self-powered,
5: Remote wakeup,
4..0: resvd */
100/2, /* u8 MaxPower; */

/* one interface */
0x09, /* u8 if_bLength; */
0x04, /* u8 if_bDescriptorType; Interface */
0x00, /* u8 if_bInterfaceNumber; */
0x00, /* u8 if_bAlternateSetting; */
0x02, /* u8 if_bNumEndpoints; */
0xff, /* u8 if_bInterfaceClass; Vendor Specific */
0xff, /* u8 if_bInterfaceSubClass; Vendor Specific */
0xff, /* u8 if_bInterfaceProtocol; Vendor Specific */
0x02, /* u8 if_iInterface; */

/* Bulk-In endpoint */
0x07, /* u8 ep_bLength; */
0x05, /* u8 ep_bDescriptorType; Endpoint */
0x81, /* u8 ep_bEndpointAddress; IN Endpoint 1 */
0x02, /* u8 ep_bmAttributes; Bulk */
0x40, 0x00, /* u16 ep_wMaxPacketSize; */
0x00, /* u8 ep_bInterval; */

/* Bulk-Out endpoint */
0x07, /* u8 ep_bLength; */
0x05, /* u8 ep_bDescriptorType; Endpoint */
0x02, /* u8 ep_bEndpointAddress; OUT Endpoint 2 */
0x02, /* u8 ep_bmAttributes; Bulk */
0x40, 0x00, /* u16 ep_wMaxPacketSize; */
0x00 /* u8 ep_bInterval; */
};

Post by Xiaofan Chen
If you have access to Linux, verify your application works under
Linux first.

It works with Linux, and with libusb-win32 1.1.12.2 on windows.

Post by Xiaofan Chen
Also please still update to the latest git. If your device is a USB
composite device with a keyboard interface, it may be helped
by this commit.

It is not composite, it's just a standard serial port with a braille
display behind.

Samuel

[Xiaofan Chen]

On Fri, May 7, 2010 at 4:26 PM, Samuel Thibault

Post by Xiaofan Chen
I see. Please post the descriptor as well. If you have Linux, please
use "lsusb -vvv". If you have Windows, please try usbview. If you
have the access to the firmware, then it is even better.

Well, actually it's qemu/hw/usb-serial.c :) which emulates a standard
FTDI 0304 USB serial chip.
It is not composite, it's just a standard serial port with a braille
display behind.

Sorry I am slow here. I did not realize that QEMU comes with
hardware components and has the qemu/hw/usb-serial.c file
you wrote. I thought it happened to have the same name
as the famous QEMU project. Now it is clear after downloading
the QEMU 0.12.3. Thanks.

But I have never heard of FTDI 0304, only FTDI232x/2232x/etc.

[Samuel Thibault]

Post by Xiaofan Chen
On Fri, May 7, 2010 at 4:26 PM, Samuel Thibault

Post by Xiaofan Chen
I see. Please post the descriptor as well. If you have Linux, please
use "lsusb -vvv". If you have Windows, please try usbview. If you
have the access to the firmware, then it is even better.

Well, actually it's qemu/hw/usb-serial.c :) which emulates a standard
FTDI 0304 USB serial chip.
It is not composite, it's just a standard serial port with a braille
display behind.

Sorry I am slow here. I did not realize that QEMU comes with
hardware components and has the qemu/hw/usb-serial.c file
you wrote. I thought it happened to have the same name
as the famous QEMU project. Now it is clear after downloading
the QEMU 0.12.3. Thanks.
But I have never heard of FTDI 0304, only FTDI232x/2232x/etc.

Ah, sorry, 0403 is just the USB ID which I got reverted from the
descriptor. The emulated chip is a 232BM indeed.

Samuel

[Xiaofan Chen]

and the basic documentation of how to build libusb-1.0 Windows
backend is not there (what to download, what to install, how to
setup MSYS, etc).

As I understand it is not different from "plain" MinGW.
When cross-compiling, I run ./configure --host=i686-w64-mingw32
or ./configure --host=x86_64-w64-mingw32 for MinGW-W64, instead
of ./configure --host=i686-mingw32 like I do with "plain" MinGW.

Cross-compiling under Ubuntu 10.04 64bit failed. Maybe Ubuntu has an
old version of mingw-w64.

***@ubuntu64:~/Desktop/build/libusb1/windows/64bit/libusb-pbatard$
./autogen.sh --host=amd64-mingw32msvc
libtoolize: putting auxiliary files in `.'.
libtoolize: copying file `./ltmain.sh'
libtoolize: putting macros in AC_CONFIG_MACRO_DIR, `m4'.
libtoolize: copying file `m4/libtool.m4'
libtoolize: copying file `m4/ltoptions.m4'
libtoolize: copying file `m4/ltsugar.m4'
libtoolize: copying file `m4/ltversion.m4'
libtoolize: copying file `m4/lt~obsolete.m4'
configure.ac:21: installing `./compile'
configure.ac:19: installing `./config.guess'
configure.ac:19: installing `./config.sub'
configure.ac:11: installing `./install-sh'
configure.ac:11: installing `./missing'
examples/Makefile.am: installing `./depcomp'
configure: WARNING: If you wanted to set the --build type, don't use --host.
If a cross compiler is detected then cross compile mode will be used.
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for amd64-mingw32msvc-strip... amd64-mingw32msvc-strip
checking for a thread-safe mkdir -p... /bin/mkdir -p
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking for amd64-mingw32msvc-gcc... amd64-mingw32msvc-gcc
checking whether the C compiler works... no
configure: error: in
`/home/mcuee/Desktop/build/libusb1/windows/64bit/libusb-pbatard':
configure: error: C compiler cannot create executables
See `config.log' for more details.

==== contents of config.log ======

This file contains any messages produced by compilers while
running configure, to aid debugging if configure makes a mistake.

It was created by libusb configure 1.0.8, which was
generated by GNU Autoconf 2.65. Invocation command line was

$ ./configure --enable-debug-log --enable-examples-build
--host=amd64-mingw32msvc

## --------- ##
## Platform. ##
## --------- ##

hostname = ubuntu64
uname -m = x86_64
uname -r = 2.6.32-21-generic
uname -s = Linux
uname -v = #32-Ubuntu SMP Fri Apr 16 08:09:38 UTC 2010

/usr/bin/uname -p = unknown
/bin/uname -X = unknown

/bin/arch = unknown
/usr/bin/arch -k = unknown
/usr/convex/getsysinfo = unknown
/usr/bin/hostinfo = unknown
/bin/machine = unknown
/usr/bin/oslevel = unknown
/bin/universe = unknown

PATH: /home/mcuee/bin
PATH: /home/mcuee/bin
PATH: /usr/local/sbin
PATH: /usr/local/bin
PATH: /usr/sbin
PATH: /usr/bin
PATH: /sbin
PATH: /bin
PATH: /usr/games
PATH: /home/mcuee/CodeSourcery/Sourcery_G++_Lite/bin


## ----------- ##
## Core tests. ##
## ----------- ##

configure:2479: checking for a BSD-compatible install
configure:2547: result: /usr/bin/install -c
configure:2558: checking whether build environment is sane
configure:2608: result: yes
configure:2657: checking for amd64-mingw32msvc-strip
configure:2673: found /usr/bin/amd64-mingw32msvc-strip
configure:2684: result: amd64-mingw32msvc-strip
configure:2749: checking for a thread-safe mkdir -p
configure:2788: result: /bin/mkdir -p
configure:2801: checking for gawk
configure:2817: found /usr/bin/gawk
configure:2828: result: gawk
configure:2839: checking whether make sets $(MAKE)
configure:2861: result: yes
configure:2967: checking for amd64-mingw32msvc-gcc
configure:2983: found /usr/bin/amd64-mingw32msvc-gcc
configure:2994: result: amd64-mingw32msvc-gcc
configure:3263: checking for C compiler version
configure:3272: amd64-mingw32msvc-gcc --version >&5
amd64-mingw32msvc-gcc (GCC) 4.4.2
Copyright (C) 2009 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

configure:3283: $? = 0
configure:3272: amd64-mingw32msvc-gcc -v >&5
Using built-in specs.
Target: amd64-mingw32msvc
Configured with:
/build/buildd/gcc-mingw32-4.4.2/build-tree/gcc-4.4.2/configure
--build=x86_64-linux-gnu --prefix=/usr --includedir='/include'
--mandir='/share/man' --infodir='/share/info' --sysconfdir=/etc
--localstatedir=/var --libexecdir='/lib/' --disable-multilib
--enable-threads --enable-sjlj-exceptions
--enable-version-specific-runtime-libs --disable-shared
--target=amd64-mingw32msvc --enable-languages=c : (reconfigured)
/build/buildd/gcc-mingw32-4.4.2/build-tree/gcc-4.4.2/configure
--build=x86_64-linux-gnu --prefix=/usr --includedir='/include'
--mandir='/share/man' --infodir='/share/info' --sysconfdir=/etc
--localstatedir=/var --libexecdir='/lib/' --disable-multilib
--enable-threads --enable-sjlj-exceptions
--enable-version-specific-runtime-libs --disable-shared
--target=amd64-mingw32msvc --enable-languages=c
Thread model: win32
gcc version 4.4.2 (GCC)
configure:3283: $? = 0
configure:3272: amd64-mingw32msvc-gcc -V >&5
amd64-mingw32msvc-gcc: '-V' option must have argument
configure:3283: $? = 1
configure:3272: amd64-mingw32msvc-gcc -qversion >&5
amd64-mingw32msvc-gcc: unrecognized option '-qversion'
amd64-mingw32msvc-gcc: no input files
configure:3283: $? = 1
configure:3303: checking whether the C compiler works
configure:3325: amd64-mingw32msvc-gcc conftest.c >&5
/usr/lib/gcc/amd64-mingw32msvc/4.4.2/../../../../amd64-mingw32msvc/bin/ld:
cannot find -lgcc
collect2: ld returned 1 exit status
configure:3329: $? = 1
configure:3367: result: no
configure: failed program was:
| /* confdefs.h */
| #define PACKAGE_NAME "libusb"
| #define PACKAGE_TARNAME "libusb"
| #define PACKAGE_VERSION "1.0.8"
| #define PACKAGE_STRING "libusb 1.0.8"
| #define PACKAGE_BUGREPORT "libusb-***@lists.sourceforge.net"
| #define PACKAGE_URL "http://www.libusb.org/"
| #define PACKAGE "libusb"
| #define VERSION "1.0.8"
| /* end confdefs.h. */
|
| int
| main ()
| {
|
| ;
| return 0;
| }
configure:3372: error: in
`/home/mcuee/Desktop/build/libusb1/windows/64bit/libusb-pbatard':
configure:3376: error: C compiler cannot create executables
See `config.log' for more details.

## ---------------- ##
## Cache variables. ##
## ---------------- ##

ac_cv_env_CC_set=
ac_cv_env_CC_value=
ac_cv_env_CFLAGS_set=
ac_cv_env_CFLAGS_value=
ac_cv_env_CPPFLAGS_set=
ac_cv_env_CPPFLAGS_value=
ac_cv_env_CPP_set=
ac_cv_env_CPP_value=
ac_cv_env_LDFLAGS_set=
ac_cv_env_LDFLAGS_value=
ac_cv_env_LIBS_set=
ac_cv_env_LIBS_value=
ac_cv_env_build_alias_set=
ac_cv_env_build_alias_value=
ac_cv_env_host_alias_set=set
ac_cv_env_host_alias_value=amd64-mingw32msvc
ac_cv_env_target_alias_set=
ac_cv_env_target_alias_value=
ac_cv_path_install='/usr/bin/install -c'
ac_cv_path_mkdir=/bin/mkdir
ac_cv_prog_AWK=gawk
ac_cv_prog_CC=amd64-mingw32msvc-gcc
ac_cv_prog_STRIP=amd64-mingw32msvc-strip
ac_cv_prog_make_make_set=yes

## ----------------- ##
## Output variables. ##
## ----------------- ##

ACLOCAL='${SHELL}
/home/mcuee/Desktop/build/libusb1/windows/64bit/libusb-pbatard/missing
--run aclocal-1.11'
AMDEPBACKSLASH=''
AMDEP_FALSE=''
AMDEP_TRUE=''
AMTAR='${SHELL}
/home/mcuee/Desktop/build/libusb1/windows/64bit/libusb-pbatard/missing
--run tar'
AM_BACKSLASH='\'
AM_CFLAGS=''
AM_DEFAULT_VERBOSITY='0'
AM_LDFLAGS=''
AR=''
AUTOCONF='${SHELL}
/home/mcuee/Desktop/build/libusb1/windows/64bit/libusb-pbatard/missing
--run autoconf'
AUTOHEADER='${SHELL}
/home/mcuee/Desktop/build/libusb1/windows/64bit/libusb-pbatard/missing
--run autoheader'
AUTOMAKE='${SHELL}
/home/mcuee/Desktop/build/libusb1/windows/64bit/libusb-pbatard/missing
--run automake-1.11'
AWK='gawk'
BUILD_EXAMPLES_FALSE=''
BUILD_EXAMPLES_TRUE=''
CC='amd64-mingw32msvc-gcc'
CCDEPMODE=''
CFLAGS=''
CPP=''
CPPFLAGS=''
CYGPATH_W='echo'
DEFS=''
DEPDIR=''
DSYMUTIL=''
DUMPBIN=''
ECHO_C=''
ECHO_N='-n'
ECHO_T=''
EGREP=''
EXEEXT=''
FGREP=''
GREP=''
INSTALL_DATA='${INSTALL} -m 644'
INSTALL_PROGRAM='${INSTALL}'
INSTALL_SCRIPT='${INSTALL}'
INSTALL_STRIP_PROGRAM='$(install_sh) -c -s'
LD=''
LDFLAGS=''
LIBOBJS=''
LIBS=''
LIBTOOL=''
LIBUSB_VERSION_MAJOR='1'
LIBUSB_VERSION_MICRO='8'
LIBUSB_VERSION_MINOR='0'
LIPO=''
LN_S=''
LTLIBOBJS=''
MAKEINFO='${SHELL}
/home/mcuee/Desktop/build/libusb1/windows/64bit/libusb-pbatard/missing
--run makeinfo'
MKDIR_P='/bin/mkdir -p'
NM=''
NMEDIT=''
OBJDUMP=''
OBJEXT=''
OS_DARWIN=''
OS_DARWIN_FALSE=''
OS_DARWIN_TRUE=''
OS_LINUX=''
OS_LINUX_FALSE=''
OS_LINUX_TRUE=''
OS_WINDOWS=''
OS_WINDOWS_FALSE=''
OS_WINDOWS_TRUE=''
OTOOL64=''
OTOOL=''
PACKAGE='libusb'
PACKAGE_BUGREPORT='libusb-***@lists.sourceforge.net'
PACKAGE_NAME='libusb'
PACKAGE_STRING='libusb 1.0.8'
PACKAGE_TARNAME='libusb'
PACKAGE_URL='http://www.libusb.org/'
PACKAGE_VERSION='1.0.8'
PATH_SEPARATOR=':'
POSIX_THREADS_FALSE=''
POSIX_THREADS_TRUE=''
RANLIB=''
RC=''
SED=''
SET_MAKE=''
SHELL='/bin/sh'
STRIP='amd64-mingw32msvc-strip'
VERSION='1.0.8'
VISIBILITY_CFLAGS=''
ac_ct_CC=''
ac_ct_DUMPBIN=''
am__EXEEXT_FALSE=''
am__EXEEXT_TRUE=''
am__fastdepCC_FALSE=''
am__fastdepCC_TRUE=''
am__include=''
am__isrc=''
am__leading_dot='.'
am__quote=''
am__tar='${AMTAR} chof - "$$tardir"'
am__untar='${AMTAR} xf -'
bindir='${exec_prefix}/bin'
build=''
build_alias=''
build_cpu=''
build_os=''
build_vendor=''
datadir='${datarootdir}'
datarootdir='${prefix}/share'
docdir='${datarootdir}/doc/${PACKAGE_TARNAME}'
dvidir='${docdir}'
exec_prefix='NONE'
host='amd64-mingw32msvc'
host_alias='amd64-mingw32msvc'
host_cpu=''
host_os=''
host_vendor=''
htmldir='${docdir}'
includedir='${prefix}/include'
infodir='${datarootdir}/info'
install_sh='${SHELL}
/home/mcuee/Desktop/build/libusb1/windows/64bit/libusb-pbatard/install-sh'
libdir='${exec_prefix}/lib'
libexecdir='${exec_prefix}/libexec'
localedir='${datarootdir}/locale'
localstatedir='${prefix}/var'
lt_ECHO='echo'
mandir='${datarootdir}/man'
mkdir_p='/bin/mkdir -p'
oldincludedir='/usr/include'
pdfdir='${docdir}'
prefix='NONE'
program_transform_name='s,x,x,'
psdir='${docdir}'
sbindir='${exec_prefix}/sbin'
sharedstatedir='${prefix}/com'
sysconfdir='${prefix}/etc'
target_alias=''

## ----------- ##
## confdefs.h. ##
## ----------- ##

/* confdefs.h */
#define PACKAGE_NAME "libusb"
#define PACKAGE_TARNAME "libusb"
#define PACKAGE_VERSION "1.0.8"
#define PACKAGE_STRING "libusb 1.0.8"
#define PACKAGE_BUGREPORT "libusb-***@lists.sourceforge.net"
#define PACKAGE_URL "http://www.libusb.org/"
#define PACKAGE "libusb"
#define VERSION "1.0.8"

configure: exit 77

[Xiaofan Chen]

Post by Xiaofan Chen

and the basic documentation of how to build libusb-1.0 Windows
backend is not there (what to download, what to install, how to
setup MSYS, etc).

As I understand it is not different from "plain" MinGW.
When cross-compiling, I run ./configure --host=i686-w64-mingw32
or ./configure --host=x86_64-w64-mingw32 for MinGW-W64, instead
of ./configure --host=i686-mingw32 like I do with "plain" MinGW.

Cross-compiling under Ubuntu 10.04 64bit failed. Maybe Ubuntu has an
old version of mingw-w64.
./autogen.sh --host=amd64-mingw32msvc

Using --build is a bit better.

***@ubuntu64:~/Desktop/build/libusb1/windows/64bit/libusb-pbatard$
./autogen.sh --build=amd64-mingw32msvc
libtoolize: putting auxiliary files in `.'.
libtoolize: copying file `./ltmain.sh'
libtoolize: putting macros in AC_CONFIG_MACRO_DIR, `m4'.
libtoolize: copying file `m4/libtool.m4'
libtoolize: copying file `m4/ltoptions.m4'
libtoolize: copying file `m4/ltsugar.m4'
libtoolize: copying file `m4/ltversion.m4'
libtoolize: copying file `m4/lt~obsolete.m4'
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... /bin/mkdir -p
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking for gcc... gcc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables...
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
checking for style of include used by make... GNU
checking dependency style of gcc... gcc3
checking build system type... x86_64-pc-mingw32msvc
checking host system type... x86_64-pc-mingw32msvc
checking for a sed that does not truncate output... /bin/sed
checking for grep that handles long lines and -e... /bin/grep
checking for egrep... /bin/grep -E
checking for fgrep... /bin/grep -F
checking for ld used by gcc... /usr/bin/ld
checking if the linker (/usr/bin/ld) is GNU ld... yes
checking for BSD- or MS-compatible name lister (nm)... /usr/bin/nm -B
checking the name lister (/usr/bin/nm -B) interface... BSD nm
checking whether ln -s works... yes
checking the maximum length of command line arguments... 8192
checking whether the shell understands some XSI constructs... yes
checking whether the shell understands "+="... yes
checking for /usr/bin/ld option to reload object files... -r
checking for objdump... objdump
checking how to recognize dependent libraries... file_magic ^x86
archive import|^x86 DLL
checking for ar... ar
checking for strip... strip
checking for ranlib... ranlib
checking command to parse /usr/bin/nm -B output from gcc object... ok
checking how to run the C preprocessor... gcc -E
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking for dlfcn.h... yes
checking for objdir... .libs
checking if gcc supports -fno-rtti -fno-exceptions... no
checking for gcc option to produce PIC... -DDLL_EXPORT -DPIC
checking if gcc PIC flag -DDLL_EXPORT -DPIC works... yes
checking if gcc static flag -static works... yes
checking if gcc supports -c -o file.o... yes
checking if gcc supports -c -o file.o... (cached) yes
checking whether the gcc linker (/usr/bin/ld) supports shared libraries... no
checking dynamic linker characteristics... Win32 ld.exe
checking how to hardcode library paths into programs... unsupported
checking whether stripping libraries is possible... yes
checking if libtool supports shared libraries... no
checking whether to build shared libraries... no
checking whether to build static libraries... yes
checking for inline... inline
checking whether gcc and cc understand -c and -o together... yes
checking operating system... Windows
checking for windres... no
checking sys/timerfd.h usability... yes
checking sys/timerfd.h presence... yes
checking for sys/timerfd.h... yes
checking whether TFD_NONBLOCK is declared... yes
checking whether to use timerfd for timing... yes
checking for struct timespec... yes
configure: creating ./config.status
config.status: creating libusb-1.0.pc
config.status: creating Makefile
config.status: creating libusb/Makefile
config.status: creating libusb/libusb-1.0.rc
config.status: creating examples/Makefile
config.status: creating doc/Makefile
config.status: creating doc/doxygen.cfg
config.status: creating config.h
config.status: executing depfiles commands
config.status: executing libtool commands

make[2]: Entering directory
`/home/mcuee/Desktop/build/libusb1/windows/64bit/libusb-pbatard/libusb'
CC libusb_1_0_la-core.lo
In file included from libusbi.h:183,
from core.c:31:
./os/threads_windows.h:31: error: expected specifier-qualifier-list
before 'DWORD'
./os/threads_windows.h:62: warning: type defaults to 'int' in
declaration of 'LONG'
./os/threads_windows.h:62: error: expected ';', ',' or ')' before '*' token
./os/threads_windows.h:63: warning: type defaults to 'int' in
declaration of 'LONG'
./os/threads_windows.h:63: error: expected ';', ',' or ')' before '*' token
./os/threads_windows.h:66: error: expected ')' before '*' token
./os/threads_windows.h:68: error: expected ')' before '*' token
./os/threads_windows.h:69: error: expected ')' before '*' token
./os/threads_windows.h:70: error: expected ')' before '*' token
./os/threads_windows.h:71: error: expected ')' before '*' token
./os/threads_windows.h:76: error: expected declaration specifiers or
'...' before 'HANDLE'
./os/threads_windows.h:78: error: expected declaration specifiers or
'...' before 'HANDLE'
In file included from libusbi.h:184,
from core.c:31:
./os/poll_windows.h:77: error: expected specifier-qualifier-list before 'HANDLE'
./os/poll_windows.h:91: error: expected ')' before 'handle'
./os/poll_windows.h:94: error: expected ')' before 'handle'
./os/poll_windows.h:95: error: expected ')' before '*' token
In file included from core.c:31:
libusbi.h:198: error: expected specifier-qualifier-list before 'HANDLE'
libusbi.h:253: error: expected specifier-qualifier-list before 'HANDLE'
libusbi.h:269: error: expected specifier-qualifier-list before 'HANDLE'
libusbi.h:311: error: expected specifier-qualifier-list before 'HANDLE'
core.c:44: error: expected '=', ',', ';', 'asm' or '__attribute__'
before 'default_context_lock'
core.c: In function 'usbi_alloc_device':
core.c:509: error: implicit declaration of function 'usbi_mutex_init'
core.c:509: error: 'struct libusb_device' has no member named 'lock'
core.c:515: error: 'struct libusb_device' has no member named 'ctx'
core.c:516: error: 'struct libusb_device' has no member named 'refcnt'
core.c:517: error: 'struct libusb_device' has no member named 'session_data'
core.c:518: error: 'struct libusb_device' has no member named 'os_priv'
core.c:520: error: implicit declaration of function 'usbi_mutex_lock'
core.c:520: error: 'struct libusb_context' has no member named 'usb_devs_lock'
core.c:521: error: 'struct libusb_device' has no member named 'list'
core.c:522: error: implicit declaration of function 'usbi_mutex_unlock'
core.c:522: error: 'struct libusb_context' has no member named 'usb_devs_lock'
core.c: In function 'usbi_sanitize_device':
core.c:542: error: 'struct libusb_device' has no member named 'ctx'
core.c:549: error: 'struct libusb_device' has no member named
'num_configurations'
core.c: In function 'usbi_get_device_by_session_id':
core.c:562: error: 'struct libusb_context' has no member named 'usb_devs_lock'
core.c:563: error: 'struct libusb_device' has no member named 'list'
core.c:563: error: 'struct libusb_device' has no member named 'list'
core.c:563: error: 'struct libusb_device' has no member named 'list'
core.c:563: error: 'struct libusb_device' has no member named 'list'
core.c:564: error: 'struct libusb_device' has no member named 'session_data'
core.c:568: error: 'struct libusb_context' has no member named 'usb_devs_lock'
core.c: In function 'libusb_get_bus_number':
core.c:662: error: 'libusb_device' has no member named 'bus_number'
core.c: In function 'libusb_get_device_address':
core.c:672: error: 'libusb_device' has no member named 'device_address'
core.c: In function 'libusb_get_max_packet_size':
core.c:725: error: 'libusb_device' has no member named 'ctx'
core.c: In function 'libusb_get_max_iso_packet_size':
core.c:776: error: 'libusb_device' has no member named 'ctx'
core.c: In function 'libusb_ref_device':
core.c:803: error: 'libusb_device' has no member named 'lock'
core.c:804: error: 'libusb_device' has no member named 'refcnt'
core.c:805: error: 'libusb_device' has no member named 'lock'
core.c: In function 'libusb_unref_device':
core.c:821: error: 'libusb_device' has no member named 'lock'
core.c:822: error: 'libusb_device' has no member named 'refcnt'
core.c:823: error: 'libusb_device' has no member named 'lock'
core.c:826: error: 'libusb_device' has no member named 'bus_number'
core.c:826: error: 'libusb_device' has no member named 'device_address'
core.c:831: error: 'libusb_device' has no member named 'ctx'
core.c:832: error: 'libusb_device' has no member named 'list'
core.c:833: error: 'libusb_device' has no member named 'ctx'
core.c:835: error: implicit declaration of function 'usbi_mutex_destroy'
core.c:835: error: 'libusb_device' has no member named 'lock'
core.c: In function 'usbi_fd_notification':
core.c:853: error: 'struct libusb_context' has no member named
'pollfd_modify_lock'
core.c:854: error: 'struct libusb_context' has no member named 'pollfd_modify'
core.c:855: error: 'struct libusb_context' has no member named
'pollfd_modify_lock'
core.c:861: error: 'struct libusb_context' has no member named
'pollfd_modify_lock'
core.c:862: error: 'struct libusb_context' has no member named 'pollfd_modify'
core.c:863: error: 'struct libusb_context' has no member named
'pollfd_modify_lock'
core.c:876: error: 'struct libusb_context' has no member named
'pollfd_modify_lock'
core.c:877: error: 'struct libusb_context' has no member named 'pollfd_modify'
core.c:878: error: 'struct libusb_context' has no member named
'pollfd_modify_lock'
core.c: In function 'libusb_open':
core.c:905: error: 'libusb_device' has no member named 'ctx'
core.c:909: error: 'libusb_device' has no member named 'bus_number'
core.c:909: error: 'libusb_device' has no member named 'device_address'
core.c:915: error: 'struct libusb_device_handle' has no member named 'lock'
core.c:921: error: 'struct libusb_device_handle' has no member named 'dev'
core.c:922: error: 'struct libusb_device_handle' has no member named
'claimed_interfaces'
core.c:923: error: 'struct libusb_device_handle' has no member named 'os_priv'
core.c:928: error: 'struct libusb_device_handle' has no member named 'lock'
core.c:933: error: 'struct libusb_context' has no member named 'open_devs_lock'
core.c:934: error: 'struct libusb_device_handle' has no member named 'list'
core.c:934: error: 'struct libusb_context' has no member named 'open_devs'
core.c:935: error: 'struct libusb_context' has no member named 'open_devs_lock'
core.c: In function 'do_close':
core.c:1005: error: 'struct libusb_context' has no member named 'open_devs_lock'
core.c:1006: error: 'struct libusb_device_handle' has no member named 'list'
core.c:1007: error: 'struct libusb_context' has no member named 'open_devs_lock'
core.c:1010: error: 'struct libusb_device_handle' has no member named 'dev'
core.c:1011: error: 'struct libusb_device_handle' has no member named 'lock'
core.c: In function 'libusb_close':
core.c:1036: error: 'libusb_device_handle' has no member named 'dev'
core.c:1045: error: 'struct libusb_context' has no member named
'pollfd_modify_lock'
core.c:1046: error: 'struct libusb_context' has no member named 'pollfd_modify'
core.c:1047: error: 'struct libusb_context' has no member named
'pollfd_modify_lock'
core.c:1054: error: 'struct libusb_context' has no member named
'pollfd_modify_lock'
core.c:1055: error: 'struct libusb_context' has no member named 'pollfd_modify'
core.c:1056: error: 'struct libusb_context' has no member named
'pollfd_modify_lock'
core.c:1072: error: 'struct libusb_context' has no member named
'pollfd_modify_lock'
core.c:1073: error: 'struct libusb_context' has no member named 'pollfd_modify'
core.c:1074: error: 'struct libusb_context' has no member named
'pollfd_modify_lock'
core.c: In function 'libusb_get_device':
core.c:1089: error: 'libusb_device_handle' has no member named 'dev'
core.c: In function 'libusb_get_configuration':
core.c:1127: error: 'libusb_device_handle' has no member named 'dev'
core.c: In function 'libusb_claim_interface':
core.c:1218: error: 'libusb_device_handle' has no member named
'claimed_interfaces'
core.c:1221: error: 'libusb_device_handle' has no member named 'lock'
core.c:1222: error: 'libusb_device_handle' has no member named
'claimed_interfaces'
core.c:1227: error: 'libusb_device_handle' has no member named
'claimed_interfaces'
core.c:1230: error: 'libusb_device_handle' has no member named 'lock'
core.c: In function 'libusb_release_interface':
core.c:1255: error: 'libusb_device_handle' has no member named
'claimed_interfaces'
core.c:1258: error: 'libusb_device_handle' has no member named 'lock'
core.c:1259: error: 'libusb_device_handle' has no member named
'claimed_interfaces'
core.c:1266: error: 'libusb_device_handle' has no member named
'claimed_interfaces'
core.c:1269: error: 'libusb_device_handle' has no member named 'lock'
core.c: In function 'libusb_set_interface_alt_setting':
core.c:1299: error: 'libusb_device_handle' has no member named
'claimed_interfaces'
core.c:1302: error: 'libusb_device_handle' has no member named 'lock'
core.c:1303: error: 'libusb_device_handle' has no member named
'claimed_interfaces'
core.c:1304: error: 'libusb_device_handle' has no member named 'lock'
core.c:1307: error: 'libusb_device_handle' has no member named 'lock'
core.c: In function 'libusb_init':
core.c:1489: error: implicit declaration of function 'usbi_mutex_static_lock'
core.c:1489: error: 'default_context_lock' undeclared (first use in
this function)
core.c:1489: error: (Each undeclared identifier is reported only once
core.c:1489: error: for each function it appears in.)
core.c:1491: error: implicit declaration of function 'usbi_mutex_static_unlock'
core.c:1501: error: 'struct libusb_context' has no member named 'timerfd'
core.c:1518: error: 'struct libusb_context' has no member named 'usb_devs_lock'
core.c:1519: error: 'struct libusb_context' has no member named 'open_devs_lock'
core.c:1521: error: 'struct libusb_context' has no member named 'open_devs'
core.c:1546: error: 'struct libusb_context' has no member named 'open_devs_lock'
core.c:1547: error: 'struct libusb_context' has no member named 'usb_devs_lock'
core.c: In function 'libusb_exit':
core.c:1564: error: 'struct libusb_context' has no member named 'open_devs'
core.c:1564: error: 'struct libusb_context' has no member named 'open_devs'
core.c:1571: error: 'default_context_lock' undeclared (first use in
this function)
core.c:1578: error: 'struct libusb_context' has no member named 'open_devs_lock'
core.c:1579: error: 'struct libusb_context' has no member named 'usb_devs_lock'
make[2]: *** [libusb_1_0_la-core.lo] Error 1
make[2]: Leaving directory
`/home/mcuee/Desktop/build/libusb1/windows/64bit/libusb-pbatard/libusb'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory
`/home/mcuee/Desktop/build/libusb1/windows/64bit/libusb-pbatard'
make: *** [all] Error 2

[Xiaofan Chen]

Post by Xiaofan Chen
Cross-compiling under Ubuntu 10.04 64bit failed. Maybe Ubuntu has an
old version of mingw-w64.

I downloaded the automatic build from mingw-w64 from Sourceforge.
The build seems to be okay. So I think it is just a Ubuntu packaging issue.

***@ubuntu64-laptop:~/Desktop/build/libusb1/libusb-pbatard$
./autogen.sh --build=x86_64-linux-gnu
libtoolize: putting auxiliary files in `.'.
libtoolize: copying file `./ltmain.sh'
libtoolize: putting macros in AC_CONFIG_MACRO_DIR, `m4'.
libtoolize: copying file `m4/libtool.m4'
libtoolize: copying file `m4/ltoptions.m4'
libtoolize: copying file `m4/ltsugar.m4'
libtoolize: copying file `m4/ltversion.m4'
libtoolize: copying file `m4/lt~obsolete.m4'
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... /bin/mkdir -p
checking for gawk... no
checking for mawk... mawk
checking whether make sets $(MAKE)... yes
checking for gcc... gcc
checking for C compiler default output file name... a.out
checking whether the C compiler works... yes
checking whether we are cross compiling... no
checking for suffix of executables...
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
checking for style of include used by make... GNU
checking dependency style of gcc... gcc3
checking build system type... x86_64-pc-linux-gnu
checking host system type... x86_64-pc-linux-gnu
checking for a sed that does not truncate output... /bin/sed
checking for grep that handles long lines and -e... /bin/grep
checking for egrep... /bin/grep -E
checking for fgrep... /bin/grep -F
checking for ld used by gcc... /usr/bin/ld
checking if the linker (/usr/bin/ld) is GNU ld... yes
checking for BSD- or MS-compatible name lister (nm)... /usr/bin/nm -B
checking the name lister (/usr/bin/nm -B) interface... BSD nm
checking whether ln -s works... yes
checking the maximum length of command line arguments... 1572864
checking whether the shell understands some XSI constructs... yes
checking whether the shell understands "+="... yes
checking for /usr/bin/ld option to reload object files... -r
checking for objdump... objdump
checking how to recognize dependent libraries... pass_all
checking for ar... ar
checking for strip... strip
checking for ranlib... ranlib
checking command to parse /usr/bin/nm -B output from gcc object... ok
checking how to run the C preprocessor... gcc -E
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking for dlfcn.h... yes
checking for objdir... .libs
checking if gcc supports -fno-rtti -fno-exceptions... no
checking for gcc option to produce PIC... -fPIC -DPIC
checking if gcc PIC flag -fPIC -DPIC works... yes
checking if gcc static flag -static works... yes
checking if gcc supports -c -o file.o... yes
checking if gcc supports -c -o file.o... (cached) yes
checking whether the gcc linker (/usr/bin/ld -m elf_x86_64) supports
shared libraries... yes
checking whether -lc should be explicitly linked in... no
checking dynamic linker characteristics... GNU/Linux ld.so
checking how to hardcode library paths into programs... immediate
checking whether stripping libraries is possible... yes
checking if libtool supports shared libraries... yes
checking whether to build shared libraries... yes
checking whether to build static libraries... yes
checking for inline... inline
checking whether gcc and cc understand -c and -o together... yes
checking operating system... Linux
checking for clock_gettime in -lrt... yes
checking sys/timerfd.h usability... yes
checking sys/timerfd.h presence... yes
checking for sys/timerfd.h... yes
checking whether TFD_NONBLOCK is declared... yes
checking whether to use timerfd for timing... yes
checking for struct timespec... yes
configure: creating ./config.status
config.status: creating libusb-1.0.pc
config.status: creating Makefile
config.status: creating libusb/Makefile
config.status: creating libusb/libusb-1.0.rc
config.status: creating examples/Makefile
config.status: creating doc/Makefile
config.status: creating doc/doxygen.cfg
config.status: creating config.h
config.status: executing depfiles commands
config.status: executing libtool commands
***@ubuntu64-laptop:~/Desktop/build/libusb1/libusb-pbatard$ make
make all-recursive
make[1]: Entering directory `/home/mcuee/Desktop/build/libusb1/libusb-pbatard'
Making all in libusb
make[2]: Entering directory
`/home/mcuee/Desktop/build/libusb1/libusb-pbatard/libusb'
CC libusb_1_0_la-core.lo
CC libusb_1_0_la-descriptor.lo
CC libusb_1_0_la-io.lo
CC libusb_1_0_la-sync.lo
CC libusb_1_0_la-linux_usbfs.lo
CCLD libusb-1.0.la
make[2]: Leaving directory
`/home/mcuee/Desktop/build/libusb1/libusb-pbatard/libusb'
Making all in doc
make[2]: Entering directory
`/home/mcuee/Desktop/build/libusb1/libusb-pbatard/doc'
make[2]: Nothing to be done for `all'.
make[2]: Leaving directory
`/home/mcuee/Desktop/build/libusb1/libusb-pbatard/doc'
Making all in examples
make[2]: Entering directory
`/home/mcuee/Desktop/build/libusb1/libusb-pbatard/examples'
CC xusb.o
CCLD xusb
CC lsusb.o
CCLD lsusb
CC dpfp.o
CCLD dpfp
CC dpfp_threaded-dpfp_threaded.o
CCLD dpfp_threaded
make[2]: Leaving directory
`/home/mcuee/Desktop/build/libusb1/libusb-pbatard/examples'
make[2]: Entering directory `/home/mcuee/Desktop/build/libusb1/libusb-pbatard'
make[2]: Leaving directory `/home/mcuee/Desktop/build/libusb1/libusb-pbatard'
make[1]: Leaving directory `/home/mcuee/Desktop/build/libusb1/libusb-pbatard'

[Xiaofan Chen]

Post by Xiaofan Chen

Post by Xiaofan Chen
Cross-compiling under Ubuntu 10.04 64bit failed. Maybe Ubuntu has an
old version of mingw-w64.

I downloaded the automatic build from mingw-w64 from Sourceforge.
The build seems to be okay. So I think it is just a Ubuntu packaging issue.
./autogen.sh --build=x86_64-linux-gnu

Oops, I made a mistake here. The above is not for cross-compiling
at all, it is for 64bit Linux build.

It seems to me the current mingw-w64 Sourceforge download
does not have DDK files at all.

***@ubuntu64:~/Desktop/build/libusb1/windows/64bit/libusb-pbatard$
./autogen.sh -build=x86_64-w64-mingw32
libtoolize: putting auxiliary files in `.'.
libtoolize: copying file `./ltmain.sh'
libtoolize: putting macros in AC_CONFIG_MACRO_DIR, `m4'.
libtoolize: copying file `m4/libtool.m4'
libtoolize: copying file `m4/ltoptions.m4'
libtoolize: copying file `m4/ltsugar.m4'
libtoolize: copying file `m4/ltversion.m4'
libtoolize: copying file `m4/lt~obsolete.m4'
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... /bin/mkdir -p
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking for gcc... gcc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables...
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
checking for style of include used by make... GNU
checking dependency style of gcc... gcc3
checking build system type... x86_64-w64-mingw32
checking host system type... x86_64-w64-mingw32
checking for a sed that does not truncate output... /bin/sed
checking for grep that handles long lines and -e... /bin/grep
checking for egrep... /bin/grep -E
checking for fgrep... /bin/grep -F
checking for ld used by gcc... /usr/bin/ld
checking if the linker (/usr/bin/ld) is GNU ld... yes
checking for BSD- or MS-compatible name lister (nm)... /usr/bin/nm -B
checking the name lister (/usr/bin/nm -B) interface... BSD nm
checking whether ln -s works... yes
checking the maximum length of command line arguments... 8192
checking whether the shell understands some XSI constructs... yes
checking whether the shell understands "+="... yes
checking for /usr/bin/ld option to reload object files... -r
checking for objdump... objdump
checking how to recognize dependent libraries... file_magic ^x86
archive import|^x86 DLL
checking for ar... ar
checking for strip... strip
checking for ranlib... ranlib
checking command to parse /usr/bin/nm -B output from gcc object... ok
checking how to run the C preprocessor... gcc -E
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking for dlfcn.h... yes
checking for objdir... .libs
checking if gcc supports -fno-rtti -fno-exceptions... no
checking for gcc option to produce PIC... -DDLL_EXPORT -DPIC
checking if gcc PIC flag -DDLL_EXPORT -DPIC works... yes
checking if gcc static flag -static works... yes
checking if gcc supports -c -o file.o... yes
checking if gcc supports -c -o file.o... (cached) yes
checking whether the gcc linker (/usr/bin/ld) supports shared libraries... no
checking dynamic linker characteristics... Win32 ld.exe
checking how to hardcode library paths into programs... unsupported
checking whether stripping libraries is possible... yes
checking if libtool supports shared libraries... no
checking whether to build shared libraries... no
checking whether to build static libraries... yes
checking for inline... inline
checking whether gcc and cc understand -c and -o together... yes
checking operating system... Windows
checking for windres... no
checking sys/timerfd.h usability... yes
checking sys/timerfd.h presence... yes
checking for sys/timerfd.h... yes
checking whether TFD_NONBLOCK is declared... yes
checking whether to use timerfd for timing... yes
checking for struct timespec... yes
configure: creating ./config.status
config.status: creating libusb-1.0.pc
config.status: creating Makefile
config.status: creating libusb/Makefile
config.status: creating libusb/libusb-1.0.rc
config.status: creating examples/Makefile
config.status: creating doc/Makefile
config.status: creating doc/doxygen.cfg
config.status: creating config.h
config.status: executing depfiles commands
config.status: executing libtool commands
***@ubuntu64:~/Desktop/build/libusb1/windows/64bit/libusb-pbatard$ make
make all-recursive
make[1]: Entering directory
`/home/mcuee/Desktop/build/libusb1/windows/64bit/libusb-pbatard'
Making all in libusb
make[2]: Entering directory
`/home/mcuee/Desktop/build/libusb1/windows/64bit/libusb-pbatard/libusb'
CC libusb_1_0_la-core.lo
In file included from libusbi.h:183,
from core.c:31:
./os/threads_windows.h:31: error: expected specifier-qualifier-list
before 'DWORD'
./os/threads_windows.h:62: warning: type defaults to 'int' in
declaration of 'LONG'
./os/threads_windows.h:62: error: expected ';', ',' or ')' before '*' token
./os/threads_windows.h:63: warning: type defaults to 'int' in
declaration of 'LONG'
./os/threads_windows.h:63: error: expected ';', ',' or ')' before '*' token
./os/threads_windows.h:66: error: expected ')' before '*' token
./os/threads_windows.h:68: error: expected ')' before '*' token
./os/threads_windows.h:69: error: expected ')' before '*' token
./os/threads_windows.h:70: error: expected ')' before '*' token
./os/threads_windows.h:71: error: expected ')' before '*' token
./os/threads_windows.h:76: error: expected declaration specifiers or
'...' before 'HANDLE'
./os/threads_windows.h:78: error: expected declaration specifiers or
'...' before 'HANDLE'
In file included from libusbi.h:184,
from core.c:31:
./os/poll_windows.h:77: error: expected specifier-qualifier-list before 'HANDLE'
./os/poll_windows.h:91: error: expected ')' before 'handle'
./os/poll_windows.h:94: error: expected ')' before 'handle'
./os/poll_windows.h:95: error: expected ')' before '*' token
In file included from core.c:31:
libusbi.h:198: error: expected specifier-qualifier-list before 'HANDLE'
libusbi.h:253: error: expected specifier-qualifier-list before 'HANDLE'
libusbi.h:269: error: expected specifier-qualifier-list before 'HANDLE'
libusbi.h:311: error: expected specifier-qualifier-list before 'HANDLE'
core.c:44: error: expected '=', ',', ';', 'asm' or '__attribute__'
before 'default_context_lock'
core.c: In function 'usbi_alloc_device':
core.c:509: error: implicit declaration of function 'usbi_mutex_init'
core.c:509: error: 'struct libusb_device' has no member named 'lock'
core.c:515: error: 'struct libusb_device' has no member named 'ctx'
core.c:516: error: 'struct libusb_device' has no member named 'refcnt'
core.c:517: error: 'struct libusb_device' has no member named 'session_data'
core.c:518: error: 'struct libusb_device' has no member named 'os_priv'
core.c:520: error: implicit declaration of function 'usbi_mutex_lock'
core.c:520: error: 'struct libusb_context' has no member named 'usb_devs_lock'
core.c:521: error: 'struct libusb_device' has no member named 'list'
core.c:522: error: implicit declaration of function 'usbi_mutex_unlock'
core.c:522: error: 'struct libusb_context' has no member named 'usb_devs_lock'
core.c: In function 'usbi_sanitize_device':
core.c:542: error: 'struct libusb_device' has no member named 'ctx'
core.c:549: error: 'struct libusb_device' has no member named
'num_configurations'
core.c: In function 'usbi_get_device_by_session_id':
core.c:562: error: 'struct libusb_context' has no member named 'usb_devs_lock'
core.c:563: error: 'struct libusb_device' has no member named 'list'
core.c:563: error: 'struct libusb_device' has no member named 'list'
core.c:563: error: 'struct libusb_device' has no member named 'list'
core.c:563: error: 'struct libusb_device' has no member named 'list'
core.c:564: error: 'struct libusb_device' has no member named 'session_data'
core.c:568: error: 'struct libusb_context' has no member named 'usb_devs_lock'
core.c: In function 'libusb_get_bus_number':
core.c:662: error: 'libusb_device' has no member named 'bus_number'
core.c: In function 'libusb_get_device_address':
core.c:672: error: 'libusb_device' has no member named 'device_address'
core.c: In function 'libusb_get_max_packet_size':
core.c:725: error: 'libusb_device' has no member named 'ctx'
core.c: In function 'libusb_get_max_iso_packet_size':
core.c:776: error: 'libusb_device' has no member named 'ctx'
core.c: In function 'libusb_ref_device':
core.c:803: error: 'libusb_device' has no member named 'lock'
core.c:804: error: 'libusb_device' has no member named 'refcnt'
core.c:805: error: 'libusb_device' has no member named 'lock'
core.c: In function 'libusb_unref_device':
core.c:821: error: 'libusb_device' has no member named 'lock'
core.c:822: error: 'libusb_device' has no member named 'refcnt'
core.c:823: error: 'libusb_device' has no member named 'lock'
core.c:826: error: 'libusb_device' has no member named 'bus_number'
core.c:826: error: 'libusb_device' has no member named 'device_address'
core.c:831: error: 'libusb_device' has no member named 'ctx'
core.c:832: error: 'libusb_device' has no member named 'list'
core.c:833: error: 'libusb_device' has no member named 'ctx'
core.c:835: error: implicit declaration of function 'usbi_mutex_destroy'
core.c:835: error: 'libusb_device' has no member named 'lock'
core.c: In function 'usbi_fd_notification':
core.c:853: error: 'struct libusb_context' has no member named
'pollfd_modify_lock'
core.c:854: error: 'struct libusb_context' has no member named 'pollfd_modify'
core.c:855: error: 'struct libusb_context' has no member named
'pollfd_modify_lock'
core.c:861: error: 'struct libusb_context' has no member named
'pollfd_modify_lock'
core.c:862: error: 'struct libusb_context' has no member named 'pollfd_modify'
core.c:863: error: 'struct libusb_context' has no member named
'pollfd_modify_lock'
core.c:876: error: 'struct libusb_context' has no member named
'pollfd_modify_lock'
core.c:877: error: 'struct libusb_context' has no member named 'pollfd_modify'
core.c:878: error: 'struct libusb_context' has no member named
'pollfd_modify_lock'
core.c: In function 'libusb_open':
core.c:905: error: 'libusb_device' has no member named 'ctx'
core.c:909: error: 'libusb_device' has no member named 'bus_number'
core.c:909: error: 'libusb_device' has no member named 'device_address'
core.c:915: error: 'struct libusb_device_handle' has no member named 'lock'
core.c:921: error: 'struct libusb_device_handle' has no member named 'dev'
core.c:922: error: 'struct libusb_device_handle' has no member named
'claimed_interfaces'
core.c:923: error: 'struct libusb_device_handle' has no member named 'os_priv'
core.c:928: error: 'struct libusb_device_handle' has no member named 'lock'
core.c:933: error: 'struct libusb_context' has no member named 'open_devs_lock'
core.c:934: error: 'struct libusb_device_handle' has no member named 'list'
core.c:934: error: 'struct libusb_context' has no member named 'open_devs'
core.c:935: error: 'struct libusb_context' has no member named 'open_devs_lock'
core.c: In function 'do_close':
core.c:1005: error: 'struct libusb_context' has no member named 'open_devs_lock'
core.c:1006: error: 'struct libusb_device_handle' has no member named 'list'
core.c:1007: error: 'struct libusb_context' has no member named 'open_devs_lock'
core.c:1010: error: 'struct libusb_device_handle' has no member named 'dev'
core.c:1011: error: 'struct libusb_device_handle' has no member named 'lock'
core.c: In function 'libusb_close':
core.c:1036: error: 'libusb_device_handle' has no member named 'dev'
core.c:1045: error: 'struct libusb_context' has no member named
'pollfd_modify_lock'
core.c:1046: error: 'struct libusb_context' has no member named 'pollfd_modify'
core.c:1047: error: 'struct libusb_context' has no member named
'pollfd_modify_lock'
core.c:1054: error: 'struct libusb_context' has no member named
'pollfd_modify_lock'
core.c:1055: error: 'struct libusb_context' has no member named 'pollfd_modify'
core.c:1056: error: 'struct libusb_context' has no member named
'pollfd_modify_lock'
core.c:1072: error: 'struct libusb_context' has no member named
'pollfd_modify_lock'
core.c:1073: error: 'struct libusb_context' has no member named 'pollfd_modify'
core.c:1074: error: 'struct libusb_context' has no member named
'pollfd_modify_lock'
core.c: In function 'libusb_get_device':
core.c:1089: error: 'libusb_device_handle' has no member named 'dev'
core.c: In function 'libusb_get_configuration':
core.c:1127: error: 'libusb_device_handle' has no member named 'dev'
core.c: In function 'libusb_claim_interface':
core.c:1218: error: 'libusb_device_handle' has no member named
'claimed_interfaces'
core.c:1221: error: 'libusb_device_handle' has no member named 'lock'
core.c:1222: error: 'libusb_device_handle' has no member named
'claimed_interfaces'
core.c:1227: error: 'libusb_device_handle' has no member named
'claimed_interfaces'
core.c:1230: error: 'libusb_device_handle' has no member named 'lock'
core.c: In function 'libusb_release_interface':
core.c:1255: error: 'libusb_device_handle' has no member named
'claimed_interfaces'
core.c:1258: error: 'libusb_device_handle' has no member named 'lock'
core.c:1259: error: 'libusb_device_handle' has no member named
'claimed_interfaces'
core.c:1266: error: 'libusb_device_handle' has no member named
'claimed_interfaces'
core.c:1269: error: 'libusb_device_handle' has no member named 'lock'
core.c: In function 'libusb_set_interface_alt_setting':
core.c:1299: error: 'libusb_device_handle' has no member named
'claimed_interfaces'
core.c:1302: error: 'libusb_device_handle' has no member named 'lock'
core.c:1303: error: 'libusb_device_handle' has no member named
'claimed_interfaces'
core.c:1304: error: 'libusb_device_handle' has no member named 'lock'
core.c:1307: error: 'libusb_device_handle' has no member named 'lock'
core.c: In function 'libusb_init':
core.c:1489: error: implicit declaration of function 'usbi_mutex_static_lock'
core.c:1489: error: 'default_context_lock' undeclared (first use in
this function)
core.c:1489: error: (Each undeclared identifier is reported only once
core.c:1489: error: for each function it appears in.)
core.c:1491: error: implicit declaration of function 'usbi_mutex_static_unlock'
core.c:1501: error: 'struct libusb_context' has no member named 'timerfd'
core.c:1518: error: 'struct libusb_context' has no member named 'usb_devs_lock'
core.c:1519: error: 'struct libusb_context' has no member named 'open_devs_lock'
core.c:1521: error: 'struct libusb_context' has no member named 'open_devs'
core.c:1546: error: 'struct libusb_context' has no member named 'open_devs_lock'
core.c:1547: error: 'struct libusb_context' has no member named 'usb_devs_lock'
core.c: In function 'libusb_exit':
core.c:1564: error: 'struct libusb_context' has no member named 'open_devs'
core.c:1564: error: 'struct libusb_context' has no member named 'open_devs'
core.c:1571: error: 'default_context_lock' undeclared (first use in
this function)
core.c:1578: error: 'struct libusb_context' has no member named 'open_devs_lock'
core.c:1579: error: 'struct libusb_context' has no member named 'usb_devs_lock'
make[2]: *** [libusb_1_0_la-core.lo] Error 1
make[2]: Leaving directory
`/home/mcuee/Desktop/build/libusb1/windows/64bit/libusb-pbatard/libusb'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory
`/home/mcuee/Desktop/build/libusb1/windows/64bit/libusb-pbatard'
make: *** [all] Error 2

***@ubuntu64:~/mingw-w64/x86_64-w64-mingw32/include/ddk$ ls -la
total 24
drwxrwxr-x 2 mcuee mcuee 4096 2010-04-14 18:57 .
drwxrwxr-x 8 mcuee mcuee 20480 2010-04-14 19:39 ..

[Michael Plante]

DWORD, LONG, and HANDLE are declared in windef.h, winnt.h, and winnt.h ,
respectively, at least in msvc. You might see if it's including windows.h
in libusb.h here:

#if (defined(_WIN32) || defined(__CYGWIN__))
#include <windows.h>
#endif



Michael


-----Original Message-----
From: Xiaofan Chen [mailto:***@gmail.com]
Sent: Saturday, May 08, 2010 7:19 AM
To: libusb-***@lists.sourceforge.net
Subject: Re: [Libusb-devel] MinGW-W64 build of libusb-1.0 Windows
Backend

Post by Xiaofan Chen

and the basic documentation of how to build libusb-1.0 Windows
backend is not there (what to download, what to install, how to
setup MSYS, etc).

As I understand it is not different from "plain" MinGW.
When cross-compiling, I run ./configure --host=i686-w64-mingw32
or ./configure --host=x86_64-w64-mingw32 for MinGW-W64, instead
of ./configure --host=i686-mingw32 like I do with "plain" MinGW.

Cross-compiling under Ubuntu 10.04 64bit failed. Maybe Ubuntu has an
old version of mingw-w64.
./autogen.sh --host=amd64-mingw32msvc

Using --build is a bit better.

***@ubuntu64:~/Desktop/build/libusb1/windows/64bit/libusb-pbatard$
./autogen.sh --build=amd64-mingw32msvc
libtoolize: putting auxiliary files in `.'.
libtoolize: copying file `./ltmain.sh'
libtoolize: putting macros in AC_CONFIG_MACRO_DIR, `m4'.
libtoolize: copying file `m4/libtool.m4'
libtoolize: copying file `m4/ltoptions.m4'
libtoolize: copying file `m4/ltsugar.m4'
libtoolize: copying file `m4/ltversion.m4'
libtoolize: copying file `m4/lt~obsolete.m4'
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... /bin/mkdir -p
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking for gcc... gcc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables...
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
checking for style of include used by make... GNU
checking dependency style of gcc... gcc3
checking build system type... x86_64-pc-mingw32msvc
checking host system type... x86_64-pc-mingw32msvc
checking for a sed that does not truncate output... /bin/sed
checking for grep that handles long lines and -e... /bin/grep
checking for egrep... /bin/grep -E
checking for fgrep... /bin/grep -F
checking for ld used by gcc... /usr/bin/ld
checking if the linker (/usr/bin/ld) is GNU ld... yes
checking for BSD- or MS-compatible name lister (nm)... /usr/bin/nm -B
checking the name lister (/usr/bin/nm -B) interface... BSD nm
checking whether ln -s works... yes
checking the maximum length of command line arguments... 8192
checking whether the shell understands some XSI constructs... yes
checking whether the shell understands "+="... yes
checking for /usr/bin/ld option to reload object files... -r
checking for objdump... objdump
checking how to recognize dependent libraries... file_magic ^x86
archive import|^x86 DLL
checking for ar... ar
checking for strip... strip
checking for ranlib... ranlib
checking command to parse /usr/bin/nm -B output from gcc object... ok
checking how to run the C preprocessor... gcc -E
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking for dlfcn.h... yes
checking for objdir... .libs
checking if gcc supports -fno-rtti -fno-exceptions... no
checking for gcc option to produce PIC... -DDLL_EXPORT -DPIC
checking if gcc PIC flag -DDLL_EXPORT -DPIC works... yes
checking if gcc static flag -static works... yes
checking if gcc supports -c -o file.o... yes
checking if gcc supports -c -o file.o... (cached) yes
checking whether the gcc linker (/usr/bin/ld) supports shared libraries...
no
checking dynamic linker characteristics... Win32 ld.exe
checking how to hardcode library paths into programs... unsupported
checking whether stripping libraries is possible... yes
checking if libtool supports shared libraries... no
checking whether to build shared libraries... no
checking whether to build static libraries... yes
checking for inline... inline
checking whether gcc and cc understand -c and -o together... yes
checking operating system... Windows
checking for windres... no
checking sys/timerfd.h usability... yes
checking sys/timerfd.h presence... yes
checking for sys/timerfd.h... yes
checking whether TFD_NONBLOCK is declared... yes
checking whether to use timerfd for timing... yes
checking for struct timespec... yes
configure: creating ./config.status
config.status: creating libusb-1.0.pc
config.status: creating Makefile
config.status: creating libusb/Makefile
config.status: creating libusb/libusb-1.0.rc
config.status: creating examples/Makefile
config.status: creating doc/Makefile
config.status: creating doc/doxygen.cfg
config.status: creating config.h
config.status: executing depfiles commands
config.status: executing libtool commands

make[2]: Entering directory
`/home/mcuee/Desktop/build/libusb1/windows/64bit/libusb-pbatard/libusb'
CC libusb_1_0_la-core.lo
In file included from libusbi.h:183,
from core.c:31:
./os/threads_windows.h:31: error: expected specifier-qualifier-list
before 'DWORD'
./os/threads_windows.h:62: warning: type defaults to 'int' in
declaration of 'LONG'
./os/threads_windows.h:62: error: expected ';', ',' or ')' before '*' token
./os/threads_windows.h:63: warning: type defaults to 'int' in
declaration of 'LONG'
./os/threads_windows.h:63: error: expected ';', ',' or ')' before '*' token
./os/threads_windows.h:66: error: expected ')' before '*' token
./os/threads_windows.h:68: error: expected ')' before '*' token
./os/threads_windows.h:69: error: expected ')' before '*' token
./os/threads_windows.h:70: error: expected ')' before '*' token
./os/threads_windows.h:71: error: expected ')' before '*' token
./os/threads_windows.h:76: error: expected declaration specifiers or
'...' before 'HANDLE'
./os/threads_windows.h:78: error: expected declaration specifiers or
'...' before 'HANDLE'
In file included from libusbi.h:184,
from core.c:31:
./os/poll_windows.h:77: error: expected specifier-qualifier-list before
'HANDLE'
./os/poll_windows.h:91: error: expected ')' before 'handle'
./os/poll_windows.h:94: error: expected ')' before 'handle'
./os/poll_windows.h:95: error: expected ')' before '*' token
In file included from core.c:31:
libusbi.h:198: error: expected specifier-qualifier-list before 'HANDLE'
libusbi.h:253: error: expected specifier-qualifier-list before 'HANDLE'
libusbi.h:269: error: expected specifier-qualifier-list before 'HANDLE'
libusbi.h:311: error: expected specifier-qualifier-list before 'HANDLE'
core.c:44: error: expected '=', ',', ';', 'asm' or '__attribute__'
before 'default_context_lock'
core.c: In function 'usbi_alloc_device':
core.c:509: error: implicit declaration of function 'usbi_mutex_init'
core.c:509: error: 'struct libusb_device' has no member named 'lock'
core.c:515: error: 'struct libusb_device' has no member named 'ctx'
core.c:516: error: 'struct libusb_device' has no member named 'refcnt'
core.c:517: error: 'struct libusb_device' has no member named 'session_data'
core.c:518: error: 'struct libusb_device' has no member named 'os_priv'
core.c:520: error: implicit declaration of function 'usbi_mutex_lock'
core.c:520: error: 'struct libusb_context' has no member named
'usb_devs_lock'
core.c:521: error: 'struct libusb_device' has no member named 'list'
core.c:522: error: implicit declaration of function 'usbi_mutex_unlock'
core.c:522: error: 'struct libusb_context' has no member named
'usb_devs_lock'
core.c: In function 'usbi_sanitize_device':
core.c:542: error: 'struct libusb_device' has no member named 'ctx'
core.c:549: error: 'struct libusb_device' has no member named
'num_configurations'
core.c: In function 'usbi_get_device_by_session_id':
core.c:562: error: 'struct libusb_context' has no member named
'usb_devs_lock'
core.c:563: error: 'struct libusb_device' has no member named 'list'
core.c:563: error: 'struct libusb_device' has no member named 'list'
core.c:563: error: 'struct libusb_device' has no member named 'list'
core.c:563: error: 'struct libusb_device' has no member named 'list'
core.c:564: error: 'struct libusb_device' has no member named 'session_data'
core.c:568: error: 'struct libusb_context' has no member named
'usb_devs_lock'
core.c: In function 'libusb_get_bus_number':
core.c:662: error: 'libusb_device' has no member named 'bus_number'
core.c: In function 'libusb_get_device_address':
core.c:672: error: 'libusb_device' has no member named 'device_address'
core.c: In function 'libusb_get_max_packet_size':
core.c:725: error: 'libusb_device' has no member named 'ctx'
core.c: In function 'libusb_get_max_iso_packet_size':
core.c:776: error: 'libusb_device' has no member named 'ctx'
core.c: In function 'libusb_ref_device':
core.c:803: error: 'libusb_device' has no member named 'lock'
core.c:804: error: 'libusb_device' has no member named 'refcnt'
core.c:805: error: 'libusb_device' has no member named 'lock'
core.c: In function 'libusb_unref_device':
core.c:821: error: 'libusb_device' has no member named 'lock'
core.c:822: error: 'libusb_device' has no member named 'refcnt'
core.c:823: error: 'libusb_device' has no member named 'lock'
core.c:826: error: 'libusb_device' has no member named 'bus_number'
core.c:826: error: 'libusb_device' has no member named 'device_address'
core.c:831: error: 'libusb_device' has no member named 'ctx'
core.c:832: error: 'libusb_device' has no member named 'list'
core.c:833: error: 'libusb_device' has no member named 'ctx'
core.c:835: error: implicit declaration of function 'usbi_mutex_destroy'
core.c:835: error: 'libusb_device' has no member named 'lock'
core.c: In function 'usbi_fd_notification':
core.c:853: error: 'struct libusb_context' has no member named
'pollfd_modify_lock'
core.c:854: error: 'struct libusb_context' has no member named
'pollfd_modify'
core.c:855: error: 'struct libusb_context' has no member named
'pollfd_modify_lock'
core.c:861: error: 'struct libusb_context' has no member named
'pollfd_modify_lock'
core.c:862: error: 'struct libusb_context' has no member named
'pollfd_modify'
core.c:863: error: 'struct libusb_context' has no member named
'pollfd_modify_lock'
core.c:876: error: 'struct libusb_context' has no member named
'pollfd_modify_lock'
core.c:877: error: 'struct libusb_context' has no member named
'pollfd_modify'
core.c:878: error: 'struct libusb_context' has no member named
'pollfd_modify_lock'
core.c: In function 'libusb_open':
core.c:905: error: 'libusb_device' has no member named 'ctx'
core.c:909: error: 'libusb_device' has no member named 'bus_number'
core.c:909: error: 'libusb_device' has no member named 'device_address'
core.c:915: error: 'struct libusb_device_handle' has no member named 'lock'
core.c:921: error: 'struct libusb_device_handle' has no member named 'dev'
core.c:922: error: 'struct libusb_device_handle' has no member named
'claimed_interfaces'
core.c:923: error: 'struct libusb_device_handle' has no member named
'os_priv'
core.c:928: error: 'struct libusb_device_handle' has no member named 'lock'
core.c:933: error: 'struct libusb_context' has no member named
'open_devs_lock'
core.c:934: error: 'struct libusb_device_handle' has no member named 'list'
core.c:934: error: 'struct libusb_context' has no member named 'open_devs'
core.c:935: error: 'struct libusb_context' has no member named
'open_devs_lock'
core.c: In function 'do_close':
core.c:1005: error: 'struct libusb_context' has no member named
'open_devs_lock'
core.c:1006: error: 'struct libusb_device_handle' has no member named 'list'
core.c:1007: error: 'struct libusb_context' has no member named
'open_devs_lock'
core.c:1010: error: 'struct libusb_device_handle' has no member named 'dev'
core.c:1011: error: 'struct libusb_device_handle' has no member named 'lock'
core.c: In function 'libusb_close':
core.c:1036: error: 'libusb_device_handle' has no member named 'dev'
core.c:1045: error: 'struct libusb_context' has no member named
'pollfd_modify_lock'
core.c:1046: error: 'struct libusb_context' has no member named
'pollfd_modify'
core.c:1047: error: 'struct libusb_context' has no member named
'pollfd_modify_lock'
core.c:1054: error: 'struct libusb_context' has no member named
'pollfd_modify_lock'
core.c:1055: error: 'struct libusb_context' has no member named
'pollfd_modify'
core.c:1056: error: 'struct libusb_context' has no member named
'pollfd_modify_lock'
core.c:1072: error: 'struct libusb_context' has no member named
'pollfd_modify_lock'
core.c:1073: error: 'struct libusb_context' has no member named
'pollfd_modify'
core.c:1074: error: 'struct libusb_context' has no member named
'pollfd_modify_lock'
core.c: In function 'libusb_get_device':
core.c:1089: error: 'libusb_device_handle' has no member named 'dev'
core.c: In function 'libusb_get_configuration':
core.c:1127: error: 'libusb_device_handle' has no member named 'dev'
core.c: In function 'libusb_claim_interface':
core.c:1218: error: 'libusb_device_handle' has no member named
'claimed_interfaces'
core.c:1221: error: 'libusb_device_handle' has no member named 'lock'
core.c:1222: error: 'libusb_device_handle' has no member named
'claimed_interfaces'
core.c:1227: error: 'libusb_device_handle' has no member named
'claimed_interfaces'
core.c:1230: error: 'libusb_device_handle' has no member named 'lock'
core.c: In function 'libusb_release_interface':
core.c:1255: error: 'libusb_device_handle' has no member named
'claimed_interfaces'
core.c:1258: error: 'libusb_device_handle' has no member named 'lock'
core.c:1259: error: 'libusb_device_handle' has no member named
'claimed_interfaces'
core.c:1266: error: 'libusb_device_handle' has no member named
'claimed_interfaces'
core.c:1269: error: 'libusb_device_handle' has no member named 'lock'
core.c: In function 'libusb_set_interface_alt_setting':
core.c:1299: error: 'libusb_device_handle' has no member named
'claimed_interfaces'
core.c:1302: error: 'libusb_device_handle' has no member named 'lock'
core.c:1303: error: 'libusb_device_handle' has no member named
'claimed_interfaces'
core.c:1304: error: 'libusb_device_handle' has no member named 'lock'
core.c:1307: error: 'libusb_device_handle' has no member named 'lock'
core.c: In function 'libusb_init':
core.c:1489: error: implicit declaration of function
'usbi_mutex_static_lock'
core.c:1489: error: 'default_context_lock' undeclared (first use in
this function)
core.c:1489: error: (Each undeclared identifier is reported only once
core.c:1489: error: for each function it appears in.)
core.c:1491: error: implicit declaration of function
'usbi_mutex_static_unlock'
core.c:1501: error: 'struct libusb_context' has no member named 'timerfd'
core.c:1518: error: 'struct libusb_context' has no member named
'usb_devs_lock'
core.c:1519: error: 'struct libusb_context' has no member named
'open_devs_lock'
core.c:1521: error: 'struct libusb_context' has no member named 'open_devs'
core.c:1546: error: 'struct libusb_context' has no member named
'open_devs_lock'
core.c:1547: error: 'struct libusb_context' has no member named
'usb_devs_lock'
core.c: In function 'libusb_exit':
core.c:1564: error: 'struct libusb_context' has no member named 'open_devs'
core.c:1564: error: 'struct libusb_context' has no member named 'open_devs'
core.c:1571: error: 'default_context_lock' undeclared (first use in
this function)
core.c:1578: error: 'struct libusb_context' has no member named
'open_devs_lock'
core.c:1579: error: 'struct libusb_context' has no member named
'usb_devs_lock'
make[2]: *** [libusb_1_0_la-core.lo] Error 1
make[2]: Leaving directory
`/home/mcuee/Desktop/build/libusb1/windows/64bit/libusb-pbatard/libusb'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory
`/home/mcuee/Desktop/build/libusb1/windows/64bit/libusb-pbatard'
make: *** [all] Error 2



--
Xiaofan http://mcuee.blogspot.com

----------------------------------------------------------------------------
--

[Xiaofan Chen]

On Sun, May 9, 2010 at 12:46 AM, Michael Plante

Post by Michael Plante
DWORD, LONG, and HANDLE are declared in windef.h, winnt.h, and winnt.h ,
respectively, at least in msvc.  You might see if it's including windows.h
#if     (defined(_WIN32) || defined(__CYGWIN__))
#include <windows.h>
#endif

I think so. I find the definitions of DWORD, LONG, and HANDLE in
the respective header files you mentioned.

***@ubuntu64:~/mingw-w64/x86_64-w64-mingw32/include$ ls wind*
windef.h windns.h windows.h windowsx.h windowsx.h16

***@ubuntu64:~$ x86_64-w64-mingw32-gcc -dM -E - </dev/null | grep WIN32
#define _WIN32 1
#define __WIN32 1
#define __WIN32__ 1
#define WIN32 1

[Michael Plante]

Post by Xiaofan Chen
On Sun, May 9, 2010 at 12:46 AM, Michael Plante

Post by Michael Plante
DWORD, LONG, and HANDLE are declared in windef.h, winnt.h, and winnt.h

,

Post by Xiaofan Chen

Post by Michael Plante
respectively, at least in msvc.  You might see if it's including

windows.h

Post by Xiaofan Chen

Post by Michael Plante
#if     (defined(_WIN32) || defined(__CYGWIN__))
#include <windows.h>
#endif

I think so. I find the definitions of DWORD, LONG, and HANDLE in
the respective header files you mentioned.
windef.h windns.h windows.h windowsx.h windowsx.h16
#define _WIN32 1
#define __WIN32 1
#define __WIN32__ 1
#define WIN32 1

No, I assumed they'd be there. What I'm asking is whether that header is
included. Do something like this:

#if     (defined(_WIN32) || defined(__CYGWIN__))
#include <windows.h>
+#error Just checking!
#endif


And see if that ever even actually gets included.

Michael

[Xiaofan Chen]

On Sun, May 9, 2010 at 10:26 AM, Michael Plante

No, I assumed they'd be there.  What I'm asking is whether that header is
 #if     (defined(_WIN32) || defined(__CYGWIN__))
 #include <windows.h>
+#error Just checking!
 #endif

I add your new line. I think there is something wrong with the mingw-w64.

***@ubuntu64:~/Desktop/build/libusb1/windows/libusb-pbatard$ make
make all-recursive
make[1]: Entering directory
`/home/mcuee/Desktop/build/libusb1/windows/libusb-pbatard'
Making all in libusb
make[2]: Entering directory
`/home/mcuee/Desktop/build/libusb1/windows/libusb-pbatard/libusb'
CC libusb_1_0_la-core.lo
In file included from libusbi.h:183,
from core.c:31:
./os/threads_windows.h:31: error: expected specifier-qualifier-list
before 'DWORD'
./os/threads_windows.h:62: warning: type defaults to 'int' in
declaration of 'LONG'
./os/threads_windows.h:62: error: expected ';', ',' or ')' before '*' token
./os/threads_windows.h:63: warning: type defaults to 'int' in
declaration of 'LONG'
./os/threads_windows.h:63: error: expected ';', ',' or ')' before '*' token
./os/threads_windows.h:66: error: expected ')' before '*' token
./os/threads_windows.h:68: error: expected ')' before '*' token
./os/threads_windows.h:69: error: expected ')' before '*' token
./os/threads_windows.h:70: error: expected ')' before '*' token
./os/threads_windows.h:71: error: expected ')' before '*' token
./os/threads_windows.h:76: error: expected declaration specifiers or
'...' before 'HANDLE'
./os/threads_windows.h:78: error: expected declaration specifiers or
'...' before 'HANDLE'
In file included from libusbi.h:184,
from core.c:31:
./os/poll_windows.h:77: error: expected specifier-qualifier-list before 'HANDLE'
./os/poll_windows.h:91: error: expected ')' before 'handle'
./os/poll_windows.h:94: error: expected ')' before 'handle'
./os/poll_windows.h:95: error: expected ')' before '*' token
In file included from core.c:31:
libusbi.h:198: error: expected specifier-qualifier-list before 'HANDLE'
libusbi.h:253: error: expected specifier-qualifier-list before 'HANDLE'
libusbi.h:269: error: expected specifier-qualifier-list before 'HANDLE'
libusbi.h:311: error: expected specifier-qualifier-list before 'HANDLE'

...

[Xiaofan Chen]

Post by Xiaofan Chen
I add your new line. I think there is something wrong with the mingw-w64.

All in all, I will just conclude that mingw-w64 is not ready or at least
the documentation of using it to build libusb-1.0 Windows backend
64bit binary is not ready.

WPG64 is the only one I have success with. It only runs under
64bit Windows though.

[Xiaofan Chen]

Post by Xiaofan Chen
All in all, I will just conclude that mingw-w64 is not ready or at least
the documentation of using it to build libusb-1.0 Windows backend
64bit binary is not ready.
WPG64 is the only one I have success with. It only runs under
64bit Windows though.

WPG64 is also working fine with libwdi, tested under Windows 7
Home Premium x64.

***@WIN7HOMEX64_PC /d/work/libusb1win32/wdi/libusb-pbatard
$ ./autogen.sh --with-ddkdir=D:/WinDDK/7600.16385.1
libtoolize: putting auxiliary files in `.'.
libtoolize: copying file `./ltmain.sh'
libtoolize: putting macros in AC_CONFIG_MACRO_DIR, `m4'.
libtoolize: copying file `m4/libtool.m4'
libtoolize: copying file `m4/ltoptions.m4'
libtoolize: copying file `m4/ltsugar.m4'
libtoolize: copying file `m4/ltversion.m4'
libtoolize: copying file `m4/lt~obsolete.m4'
/usr/share/aclocal/aalib.m4:12: warning: underquoted definition of AM_PATH_AALIB

/usr/share/aclocal/aalib.m4:12: run info '(automake)Extending aclocal'
/usr/share/aclocal/aalib.m4:12: or see http://sources.redhat.com/automake/auto
make.html#Extending-aclocal
checking for a BSD-compatible install... /bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... /bin/mkdir -p
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking for gcc... gcc
checking for C compiler default output file name... a.exe
checking whether the C compiler works... yes
checking whether we are cross compiling... no
checking for suffix of executables... .exe
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
checking for style of include used by make... GNU
checking dependency style of gcc... gcc3
checking build system type... i686-pc-mingw32
checking host system type... i686-pc-mingw32
checking how to print strings... printf
checking for a sed that does not truncate output... /bin/sed
checking for grep that handles long lines and -e... /bin/grep
checking for egrep... /bin/grep -E
checking for fgrep... /bin/grep -F
checking for ld used by gcc... c:/msys/system64/x86_64-w64-mingw32/bin/ld.exe
checking if the linker (c:/msys/system64/x86_64-w64-mingw32/bin/ld.exe) is GNU l
d... yes
checking for BSD- or MS-compatible name lister (nm)... /usr/system64/bin/nm
checking the name lister (/usr/system64/bin/nm) interface... BSD nm
checking whether ln -s works... yes
checking the maximum length of command line arguments... 8192
checking whether the shell understands some XSI constructs... yes
checking whether the shell understands "+="... yes
checking for c:/msys/system64/x86_64-w64-mingw32/bin/ld.exe option to reload obj
ect files... -r
checking for objdump... objdump
checking how to recognize dependent libraries... file_magic ^x86 archive import|
^x86 DLL
checking for ar... ar
checking for strip... strip
checking for ranlib... ranlib
checking command to parse /usr/system64/bin/nm output from gcc object... ok
checking how to run the C preprocessor... gcc -E
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking for dlfcn.h... yes
checking for objdir... .libs
checking if gcc supports -fno-rtti -fno-exceptions... no
checking for gcc option to produce PIC... -DDLL_EXPORT -DPIC
checking if gcc PIC flag -DDLL_EXPORT -DPIC works... yes
checking if gcc static flag -static works... yes
checking if gcc supports -c -o file.o... yes
checking if gcc supports -c -o file.o... (cached) yes
checking whether the gcc linker (c:/msys/system64/x86_64-w64-mingw32/bin/ld.exe)
supports shared libraries... yes
checking whether -lc should be explicitly linked in... yes
checking dynamic linker characteristics... Win32 ld.exe
checking how to hardcode library paths into programs... immediate
checking whether stripping libraries is possible... yes
checking if libtool supports shared libraries... yes
checking whether to build shared libraries... yes
checking whether to build static libraries... yes
checking for inline... inline
checking whether gcc and cc understand -c and -o together... yes
checking development environment... MinGW
checking for windres... windres
checking whether the compiler can produce 32 bit binaries... yes
checking whether the compiler can produce 64 bit binaries... yes
configure: will produce a 32 bit library, compatible with 64 bit platforms
checking for D:/WinDDK/7600.16385.1/redist/wdf/amd64/WdfCoInstaller01009.dll...
yes
checking for D:/WinDDK/7600.16385.1/redist/winusb/amd64/winusbcoinstaller2.dll..
. yes
checking for D:/WinDDK/7600.16385.1/redist/wdf/x86/WdfCoInstaller01009.dll... ye
s
checking for D:/WinDDK/7600.16385.1/redist/winusb/x86/winusbcoinstaller2.dll...
yes
configure: creating ./config.status
config.status: creating Makefile
config.status: creating libwdi/Makefile
config.status: creating examples/Makefile
config.status: creating config.h
config.status: executing depfiles commands
config.status: executing libtool commands

***@WIN7HOMEX64_PC /d/work/libusb1win32/wdi/libusb-pbatard
$ make
(CDPATH="${ZSH_VERSION+.}:" && cd . && /bin/sh /d/work/libusb1win32/wdi/libusb-p
batard/missing --run autoheader)
rm -f stamp-h1
touch config.h.in
cd . && /bin/sh ./config.status config.h
config.status: creating config.h
config.status: config.h is unchanged
make all-recursive
make[1]: Entering directory `/d/work/libusb1win32/wdi/libusb-pbatard'
Making all in libwdi
make[2]: Entering directory `/d/work/libusb1win32/wdi/libusb-pbatard/libwdi'
CC embedder.o
CCLD embedder.exe
CC installer_x86-installer.o
CCLD installer_x86.exe
CC installer_x64-installer.o
CCLD installer_x64.exe
./embedder.exe resource.h
Embedding 'D:\WinDDK\7600.16385.1\redist\wdf\x86\WdfCoInstaller01009.dll'
Embedding 'D:\WinDDK\7600.16385.1\redist\winusb\x86\winusbcoinstaller2.dll'
Embedding 'd:\work\libusb1win32\wdi\libusb-pbatard\libwdi\installer_x86.exe'
Embedding 'D:\WinDDK\7600.16385.1\redist\wdf\amd64\WdfCoInstaller01009.dll'
Embedding 'D:\WinDDK\7600.16385.1\redist\winusb\amd64\winusbcoinstaller2.dll'
Embedding 'd:\work\libusb1win32\wdi\libusb-pbatard\libwdi\installer_x64.exe'
Embedding 'D:\WinDDK\7600.16385.1\license.rtf'
make all-am
make[3]: Entering directory `/d/work/libusb1win32/wdi/libusb-pbatard/libwdi'
CC libwdi_la-logging.lo
CC libwdi_la-libwdi.lo
/bin/sh ../libtool --mode=compile windres -i libwdi.rc -o libwdi_rc.lo
libtool: compile: windres -i libwdi.rc -DDLL_EXPORT -DPIC -o .libs/libwdi_rc.o

libtool: compile: windres -i libwdi.rc -o libwdi_rc.o >/dev/null 2>&1
CCLD libwdi.la
Creating library file: .libs/libwdi.dll.a
make[3]: Leaving directory `/d/work/libusb1win32/wdi/libusb-pbatard/libwdi'
make[2]: Leaving directory `/d/work/libusb1win32/wdi/libusb-pbatard/libwdi'
Making all in examples
make[2]: Entering directory `/d/work/libusb1win32/wdi/libusb-pbatard/examples'
CC zadic-zadic.o
CCLD zadic.exe
CC zadig-zadig.o
CC zadig-zadig_stdlg.o
zadig_stdlg.c: In function 'About_URL':
zadig_stdlg.c:239:31: warning: cast from pointer to integer of different size
/bin/sh ../libtool --mode=compile windres -i zadig.rc -o zadig_rc.o
libtool: compile: windres -i zadig.rc -DDLL_EXPORT -DPIC -o .libs/zadig_rc.o
libtool: compile: windres -i zadig.rc -o zadig_rc.o >/dev/null 2>&1
CCLD zadig.exe
make[2]: Leaving directory `/d/work/libusb1win32/wdi/libusb-pbatard/examples'
make[2]: Entering directory `/d/work/libusb1win32/wdi/libusb-pbatard'
make[2]: Leaving directory `/d/work/libusb1win32/wdi/libusb-pbatard'
make[1]: Leaving directory `/d/work/libusb1win32/wdi/libusb-pbatard'

[Michael Plante]

I guess I'm not entirely trusting of the command line arguments, since I
don't know what went into them. You may be right. But it just looks like
those types aren't defined when you go to compile.



-----Original Message-----
From: Michael Plante [mailto:***@gmail.com]
Sent: Saturday, May 08, 2010 9:27 PM
To: libusb-***@lists.sourceforge.net
Subject: RE: [Libusb-devel] MinGW-W64 build of libusb-1.0 Windows
Backend

Post by Xiaofan Chen
On Sun, May 9, 2010 at 12:46 AM, Michael Plante

Post by Michael Plante
DWORD, LONG, and HANDLE are declared in windef.h, winnt.h, and winnt.h

,

Post by Xiaofan Chen

Post by Michael Plante
respectively, at least in msvc.  You might see if it's including

windows.h

Post by Xiaofan Chen

Post by Michael Plante
#if     (defined(_WIN32) || defined(__CYGWIN__))
#include <windows.h>
#endif

I think so. I find the definitions of DWORD, LONG, and HANDLE in
the respective header files you mentioned.
windef.h windns.h windows.h windowsx.h windowsx.h16
#define _WIN32 1
#define __WIN32 1
#define __WIN32__ 1
#define WIN32 1

No, I assumed they'd be there. What I'm asking is whether that header is
included. Do something like this:

#if     (defined(_WIN32) || defined(__CYGWIN__))
#include <windows.h>
+#error Just checking!
#endif


And see if that ever even actually gets included.

Michael

[Alan Stern]

Post by Pete Batard
Well, it's definitely not seen as a composite device in XP, and I'm not
seeing any "claimed interface X" debug message in the libusb output, so
I'm starting to think there's a claim_interface missing in their code.
Or can control requests be issued on Linux without first claiming an
interface?

They can -- depending on the type and recipient of the control request.
With USB_TYPE_VENDOR, anything goes; no interface has to be claimed.
For the other types, it depends on the recipient.

With USB_RECIP_DEVICE and USB_RECIP_OTHER there is no need to claim an
interface, because there is no way to associate a particular interface
with the control request. On the other hand, with USB_RECIP_INTERFACE
and USB_RECIP_ENDPOINT the proper interface _does_ need to be claimed
(with USB_RECIP_ENDPOINT it is the interface to which the endpoint
belongs).

But the matter is slightly more complicated, because if you issue one
of these requests without first claiming the interface, the kernel will
automatically try to claim the interface on your behalf. If the claim
fails (i.e., something else already owns the interface) then the
control request submission will fail.

At the moment, Linux treats USB_RECIP_PORT and USB_RECIP_RPIPE (part of
the Wireless USB spec) like USB_RECIP_DEVICE.

Alan Stern

[Pete Batard]

Post by Alan Stern

Post by Pete Batard
Or can control requests be issued on Linux without first claiming an
interface?

They can -- depending on the type and recipient of the control request.

Thanks for the info.

Following on my last reply to Qui's issue, do we know what happens with
the "ioctl(fd, IOCTL_USBFS_SETCONFIG, &config)" that occurs on Linux
when set_configuration is called?

I'd say this should send control request to the device, using
USB_RECIP_DEVICE, so the line "It is up to your application to ensure
the correct configuration is selected before you attempt to claim
interfaces and perform other operations" we have in the
libusb_set_configuration documentation would apply.

Unfortunately the current Windows USB APIs (WinUSB & HID) force us to go
through an interface for all control requests, and can only use the
default configuration, so I think we might have to update our
documentation...

Regards,

/Pete

[Alan Stern]

Post by Pete Batard

Post by Alan Stern

Post by Pete Batard
Or can control requests be issued on Linux without first claiming an
interface?

They can -- depending on the type and recipient of the control request.

Thanks for the info.
Following on my last reply to Qui's issue, do we know what happens with
the "ioctl(fd, IOCTL_USBFS_SETCONFIG, &config)" that occurs on Linux
when set_configuration is called?

Well, _I_ know... Whether or not _we_ know is therefore kind of an
existential question. :-)

Post by Pete Batard
I'd say this should send control request to the device, using
USB_RECIP_DEVICE, so the line "It is up to your application to ensure
the correct configuration is selected before you attempt to claim
interfaces and perform other operations" we have in the
libusb_set_configuration documentation would apply.

Correct.

Post by Pete Batard
Unfortunately the current Windows USB APIs (WinUSB & HID) force us to go
through an interface for all control requests, and can only use the
default configuration, so I think we might have to update our
documentation...

Going through an interface for Set-Config makes no sense at all. For
instance, what happens if the device is in an unconfigured state (as it
is when initially enumerated)? When the device is unconfigured there
_are_ no interfaces to go through, and it can't get to a configured
state without receiving a Set-Config request. Catch-22.

In the interest of maintaining maximum consistency among the various
back ends, I suggest changing the Windows implementation so that it
automatically claims an interface for you when carrying out a
set_configuration call (if you haven't already claimed one).

Concerning this "default configuration only" restriction: If you do
submit a Set-Config request for the default configuration, does
Windows then send the corresponding control request to the device? If
it doesn't, then what use is that call in Windows?

Alan Stern

[Pete Batard]

Post by Alan Stern
Going through an interface for Set-Config makes no sense at all.

I agree with that, except we're trying to work around Microsoft's API
limitations by manually sending a configuration control request, because
there's no set-config API call.
Right now, this is a part of the code that is a bit experimental, as I
haven't tested what happens when sending a set-config request for
something else but the default config to a device that has multiple
confs. The set-config we currently implement is more a means for a user
application to reset part of the device with default conf, should it be
used in this fashion by the hardware.
When we have libusb0.sys support, we should be able to switch
configurations in a more proper manner.

Post by Alan Stern
For
instance, what happens if the device is in an unconfigured state (as it
is when initially enumerated)?

My understanding is that Windows issues a set-config request, from
kernel mode, for the first available configuration when the device is
plugged, and doesn't require an interface then.

After that, the OS considers that the config is set in stone, and does
not provide any means for user APIs to change it.

Post by Alan Stern
In the interest of maintaining maximum consistency among the various
back ends, I suggest changing the Windows implementation so that it
automatically claims an interface for you when carrying out a
set_configuration call (if you haven't already claimed one).

That's part of why I implemented autoclaim as an experimental feature
(these recent issues with set-config really stem from switching the
feature off in the latest versions of the code).

I guess I'll re-enable the feature then. I can try to modify it so that
it only applies to set-config though, if people feel that autoclaiming
interfaces for all requests is going too far.

Post by Alan Stern
Concerning this "default configuration only" restriction: If you do
submit a Set-Config request for the default configuration, does
Windows then send the corresponding control request to the device?

I don't think Windows goes as far as filtering control requests it
doesn't like, so I assume set-config is sent to the device.
Haven't had a chance to test that however...

Regards,

/Pete

[Peter Stuge]

Hi,

I didn't completely understand autoclaim before but now I get why it
was implemented. I am also even more convinced that it should not be
done.

Post by Pete Batard

Post by Alan Stern
Going through an interface for Set-Config makes no sense at all.

I agree with that, except we're trying to work around Microsoft's API
limitations by manually sending a configuration control request,
because there's no set-config API call.

I think we should simply mirror that it is unsupported by the WinUSB
driver. If the user wants to work around that by sending a control
request on their own then that's fine and good, since maybe there's
another system API at a later point, which also doesn't support
set_configuration.

Post by Pete Batard
Right now, this is a part of the code that is a bit experimental,

I say move it out to it's own branch, or at least into a commit.

It is now absolutely clear to me that the WinUSB backend-backend will
only ever offer second class support for libusb programs. In many
cases that will be enough, and it has some very important advantages,
but the only way to use full libusb API will continue to be with
libusb0.sys.

Does that fit with the current code structure?

Post by Pete Batard
The set-config we currently implement is more a means for a user
application to reset part of the device with default conf, should
it be used in this fashion by the hardware.

Such a set-config is basically a layering violation it might also
affect WinUSB.sys negatively.

Post by Pete Batard
When we have libusb0.sys support, we should be able to switch
configurations in a more proper manner.

Yep.

Post by Pete Batard

Post by Alan Stern
For instance, what happens if the device is in an unconfigured
state (as it is when initially enumerated)?

My understanding is that Windows issues a set-config request, from
kernel mode, for the first available configuration when the device
is plugged, and doesn't require an interface then.

My guess is that this is done by the WinUSB driver. Does the
libusb0.sys driver also issue set-config?

Post by Pete Batard
After that, the OS considers that the config is set in stone, and
does not provide any means for user APIs to change it.

Nod, user APIs, but with a kernel driver such as libusb0.sys it's
possible.

Post by Pete Batard

Post by Alan Stern
In the interest of maintaining maximum consistency among the various
back ends, I suggest changing the Windows implementation so that it
automatically claims an interface for you when carrying out a
set_configuration call (if you haven't already claimed one).

That's part of why I implemented autoclaim as an experimental feature

I didn't completely understand the motivation, if I had I would have
been able to put forward my argument much sooner.

I suggest that the WinUSB backend must not try to offer functionality
which is missing from lower level APIs, if that has any side effects,
such as claiming an interface.

Post by Pete Batard
(these recent issues with set-config really stem from switching the
feature off in the latest versions of the code).

Good thing that it happened, so that this discussion came out. :)

Post by Pete Batard
I guess I'll re-enable the feature then.

Please don't. I would move it out and return failure for
_set_configuration() on Windows until the libusb0.sys backend-backend
is in place.

Post by Pete Batard
I can try to modify it so that it only applies to set-config
though, if people feel that autoclaiming interfaces for all
requests is going too far.

I think this is a good idea!

Post by Pete Batard

Post by Alan Stern
Concerning this "default configuration only" restriction: If you do
submit a Set-Config request for the default configuration, does
Windows then send the corresponding control request to the device?

I don't think Windows goes as far as filtering control requests it
doesn't like, so I assume set-config is sent to the device.
Haven't had a chance to test that however...

I also don't think "Windows" will filter anything, but I can see that
WinUSB might do so. Best be clear about the players, since there are
a couple of different drivers and APIs.


//Peter

[Pete Batard]

Post by Peter Stuge
It is now absolutely clear to me that the WinUSB backend-backend will
only ever offer second class support for libusb programs. In many
cases that will be enough, and it has some very important advantages,
but the only way to use full libusb API will continue to be with
libusb0.sys.
Does that fit with the current code structure?

Can you clarify what you mean? We currently have WinUSB plus HID plus
composite parent (which is a different game altogether) support in the
Windows backend, and as Graeme demonstrated, we can (and will
eventually) add libusb0.sys, so I'm not sure I understand the concern here.
Our code is not constrained by WinUSB.

As a matter of fact, I recently libusb0.sys installation to libwdi
(still tweaking it) in preparation for future libusb0.sys support in the
Windows backend.

Now, how fast libusb0.sys is going to be integrated is a completely
different story...

Post by Peter Stuge
My guess is that this is done by the WinUSB driver. Does the
libusb0.sys driver also issue set-config?

There's a possibility that it's done by the OS before the driver init
occurs. I see that libusb0.sys has a set-config call, but that doesn't
guarantee that a set-config is not sent by the OS, independently of the
driver. I'm not really planning to check that anytime soon (prioritizing
other stuff - still haven't gotten back to Samuel on his issue for
instance), but if someone wants to run a trace and see what happens, I'd
be interested to know.

Post by Peter Stuge
I suggest that the WinUSB backend must not try to offer functionality
which is missing from lower level APIs, if that has any side effects,
such as claiming an interface.

OK, that's something that has actually puzzled me for some time: can
someone point to a real life situation where autoclaiming interfaces as
they are needed is detrimental? And is the claiming of interfaces part
of the USB specs or is it just a byproduct of the library having
originated from Linux? What are the actual benefits of claiming
interfaces manually?
If someone issues a request and the interface is not claimed, I doubt
their intention was to generate an error and nothing else, so, apart
from API harmonization (but that can happen one way or the other) I have
a hard time seeing autoclaim as a bad side effect. What's more I don't
remember seeing complaints about autoclaim from our Windows users so
far. If it was that bad, I would have expected someone to let us know.

Right now, my opinion would be that autoclaim should instead be part of
libusb for all platforms, as I'm not sure I see the point of forcing
everybody to claim interfaces manually.

But maybe someone can clarify that purpose...

Post by Peter Stuge

Post by Pete Batard
I guess I'll re-enable the feature then.

Please don't. I would move it out and return failure for
_set_configuration() on Windows until the libusb0.sys backend-backend
is in place.

I'd like to leave it at least for set-configuration, unless someone can
highlight the danger of claiming an interface there.

Post by Peter Stuge
I also don't think "Windows" will filter anything, but I can see that
WinUSB might do so. Best be clear about the players, since there are
a couple of different drivers and APIs.

That's what releasing the Windows backend and getting more people to use
it should help us figure out.

Regards,

/Pete

[Xiaofan Chen]

Post by Peter Stuge
It is now absolutely clear to me that the WinUSB backend-backend will
only ever offer second class support for libusb programs. In many
cases that will be enough, and it has some very important advantages,
but the only way to use full libusb API will continue to be with
libusb0.sys.

Nice to hear that.

Post by Peter Stuge

Post by Pete Batard
The set-config we currently implement is more a means for a user
application to reset part of the device with default conf, should
it be used in this fashion by the hardware.

Such a set-config is basically a layering violation it might also
affect WinUSB.sys negatively.

It is useful sometimes under Linux -- to act as a light-weight
reset than libusb_reset_device.

[Xiaofan Chen]

BTW, the implementation of libusb_set_configuration() was
actively discussed last time. It is a problematic one, not
only for Windows, but also for Linux and Mac OS X.

Reference:
http://libusb.sourceforge.net/api-1.0/caveats.html
http://sourceforge.net/mailarchive/forum.php?thread_name=483ED6D6.50109%40gentoo.org&forum_name=libusb-devel

Long discussion for similar problems in OpenUSB.
http://sourceforge.net/mailarchive/message.php?msg_id=20080823061344.GC6576%40gumby.local

There are other potential problematic libusb-1.0 APIs,
like the libusb_reset_device.

But I remember that libusb_claim_interface() has never really
caused heavy discussion last time. After all, it is a logical operation.

++++++++++++++++
http://libusb.sourceforge.net/api-1.0/group__dev.html#ga32fabedf5f13fdecf1cb33acdb19b57a

Claim an interface on a given device handle.
You must claim the interface you wish to use before you can
perform I/O on any of its endpoints.

It is legal to attempt to claim an already-claimed interface, in which
case libusb just returns 0 without doing anything.

Claiming of interfaces is a purely logical operation; it does not
cause any requests to be sent over the bus. Interface claiming is
used to instruct the underlying operating system that your application
wishes to take ownership of the interface.

This is a non-blocking function.
++++++++++++++++

Tim Robers mentioned that it is has no meaning under Windows,
but the API needs it.
http://old.nabble.com/Claiming-interface-in-Windows-XP-td27869743.html

Post by Xiaofan Chen

Post by Peter Stuge

Post by Pete Batard
The set-config we currently implement is more a means for a user
application to reset part of the device with default conf, should
it be used in this fashion by the hardware.

Such a set-config is basically a layering violation it might also
affect WinUSB.sys negatively.

It is useful sometimes under Linux -- to act as a light-weight
reset than libusb_reset_device.

[Graeme Gill]

Versions up to 0.1.12.2 and the current snapshots do not
issue set-configuration. But it confused users sometimes.
Eg: http://www.microchip.com/forums/tm.aspx?m=329309
And often Linux libusb programs do not use this
usb_set_configuration() calls. So we decided to change
this behavior. Graeme's own libusb-win32 branch also has
a similar (but simpler) change.

It was just one particular device I'm trying to support
that gets confused without the OS/driver calling set_configuration().
It may be doing something strange (like changing it's PID
on set_configuration()), and without this it would go into
an endless cycle of resets on MSWin. (It's the HCFR - see
<http://www.homecinema-fr.com/colorimetre/index_en.php>).

Graeme Gill.

[Xiaofan Chen]

Post by Graeme Gill

Versions up to 0.1.12.2 and the current snapshots do not
issue set-configuration. But it confused users sometimes.
Eg: http://www.microchip.com/forums/tm.aspx?m=329309
And often Linux libusb programs do not use this
usb_set_configuration() calls. So we decided to change
this behavior. Graeme's own libusb-win32 branch also has
a similar (but simpler) change.

It was just one particular device I'm trying to support
that gets confused without the OS/driver calling set_configuration().
It may be doing something strange (like changing it's PID
on set_configuration()), and without this it would go into
an endless cycle of resets on MSWin. (It's the HCFR - see
<http://www.homecinema-fr.com/colorimetre/index_en.php>).

Thanks. Interestingly this more I was searching for some
libusb-win32 related links and I found HCFR as well. ;-)

[Graeme Gill]

Post by Peter Stuge
It is now absolutely clear to me that the WinUSB backend-backend will
only ever offer second class support for libusb programs. In many
cases that will be enough, and it has some very important advantages,
but the only way to use full libusb API will continue to be with
libusb0.sys.

I think that's an over reaction. Once the more system dependant
exotica is taken care of (setting configuration, claiming interfaces),
the important part (sending and receiving messages) has reasonable
coverage with winusb. It is likely to work with a lot of devices.
The autoclaim certainly didn't interfere with my libusb-win32 V0.1
setup logic, it all just worked. That said, libusb.sys is much
more flexible.

Post by Peter Stuge
Good thing that it happened, so that this discussion came out. :)

Not really, it seems instead to indicate that this feature was the
right approach.

Post by Peter Stuge

Post by Pete Batard
I guess I'll re-enable the feature then.

Please don't. I would move it out and return failure for
_set_configuration() on Windows until the libusb0.sys backend-backend
is in place.

That breaks a lot of code that works fine with winusb currently. This
would therefore be a backwards move.

Graeme Gill.

[Alan Stern]

Post by Pete Batard
OK, that's something that has actually puzzled me for some time: can
someone point to a real life situation where autoclaiming interfaces as
they are needed is detrimental?

If program A manages to accidentally autoclaim an interface while
program B needs to use that interface, you get into trouble.

Post by Pete Batard
And is the claiming of interfaces part
of the USB specs

The USB spec does not mention anything about claiming interfaces, as
far as I know. The notion is beyond its scope (although the spec
doesn't hesitate to include other host-related things that are also
beyond its scope).

Post by Pete Batard
or is it just a byproduct of the library having
originated from Linux?

That's probably what happened. Although the idea makes sense in
general.

Post by Pete Batard
What are the actual benefits of claiming
interfaces manually?

As opposed to not claiming them at all? It provides a notion of
"ownership" which can be important -- you generally don't want two
different programs trying to control the same device at the same time.
However this notion applies at the OS level, not the application level.

As opposed to claiming them automatically? The user gets more control.
The advantages are twofold: You can claim an interface before starting
to use it, and you can release an interface while still claiming others
on the same device.

Post by Pete Batard
If someone issues a request and the interface is not claimed, I doubt
their intention was to generate an error and nothing else,

If someone issues a read request before opening the file descriptor,
their intention was probably not to generate an error. Nevertheless,
that's what happens.

The analogy isn't perfect, because with an unopened file descriptor the
OS doesn't know where to read from. Still, I think the same idea
applies.

Post by Pete Batard
so, apart
from API harmonization (but that can happen one way or the other) I have
a hard time seeing autoclaim as a bad side effect. What's more I don't
remember seeing complaints about autoclaim from our Windows users so
far. If it was that bad, I would have expected someone to let us know.
Right now, my opinion would be that autoclaim should instead be part of
libusb for all platforms, as I'm not sure I see the point of forcing
everybody to claim interfaces manually.
But maybe someone can clarify that purpose...

It is probably an historical remnant dating from the original design of
libusb.

Post by Pete Batard
I'd like to leave it at least for set-configuration, unless someone can
highlight the danger of claiming an interface there.

The danger there is that you claim an interface without really using
it. It would be better if you autorelease the interface when the
set-config completes.

Alan Stern

[Pete Batard]

Post by Alan Stern
If program A manages to accidentally autoclaim an interface while
program B needs to use that interface, you get into trouble.

Not sure about the accidental part. If program A manages to claim an
interface, then it probably has some use for it, so it boils down to
handling concurrency between two apps, knowing that one or the other
should receive something like ERROR_BUSY and be made aware there's a
concurrency problem.

Granted, having autorelease along with autoclaim makes more sense than
having autoclaim alone in this scenario, and there might be the
performance aspect to consider, if autoclaim is lazily used on all
transactions (though, without autorelease, the impact would be minimal,
as actual claiming would occur only once).

Post by Alan Stern

Post by Pete Batard
What are the actual benefits of claiming
interfaces manually?

As opposed to claiming them automatically?

Should have been more specific there. What I meant was: "What are the
advantages of being forced to claim interfaces manually *always*, as
opposed to claiming them automatically when required while still leaving
the possibility to claim them manually, which is what the current
autoclaim implementation does.
Not planning to break the libusb API just yet... ;)

Post by Alan Stern
The advantages are twofold: You can claim an interface before starting
to use it,

Which I read as "you can block an interface from being used by other
processes and keep exclusive access".
But if that's really what you want to do, you can still issue a manual
claim, even with autoclaim in place.

Post by Alan Stern
and you can release an interface while still claiming others
on the same device.

Again, something that can still be done even with autoclaim, though you
then need to figure out the interface autoclaim picked to release it.
This is where having autorelease along with autoclaim would help.

Post by Alan Stern

Post by Pete Batard
If someone issues a request and the interface is not claimed, I doubt
their intention was to generate an error and nothing else,

If someone issues a read request before opening the file descriptor,
their intention was probably not to generate an error. Nevertheless,
that's what happens.
The analogy isn't perfect, because with an unopened file descriptor the
OS doesn't know where to read from. Still, I think the same idea
applies.

I guess that's a matter of design consideration. There's probably a good
chance that if actual file names or inodes were fed as a parameter on
read, rather than an fd, some implementation of read would try to open
the file automatically if not already open. More likely in a Windows
world than UNIX though. It's more a matter of measuring the pros and
cons of adding such a feature.

Post by Alan Stern

Post by Pete Batard
I'd like to leave it at least for set-configuration, unless someone can
highlight the danger of claiming an interface there.

The danger there is that you claim an interface without really using
it. It would be better if you autorelease the interface when the
set-config completes.

Agreed.

Regards,

/Pete

[Alan Stern]

Post by Pete Batard

Post by Alan Stern
If program A manages to accidentally autoclaim an interface while
program B needs to use that interface, you get into trouble.

Not sure about the accidental part. If program A manages to claim an
interface, then it probably has some use for it, so it boils down to
handling concurrency between two apps, knowing that one or the other
should receive something like ERROR_BUSY and be made aware there's a
concurrency problem.

True, except in the case where program A "accidentally" claims an
interface by doing a set-config. The program hasn't really claimed
anything -- the backend did so in order to carry out the set-config --
and the program has no real use for the interface (it's not trying to
send anything to the interface's endpoints, for example).
Nevertheless, if the interface isn't autoreleased afterward then you've
got a kind of resource leak.

Post by Pete Batard
Granted, having autorelease along with autoclaim makes more sense than
having autoclaim alone in this scenario, and there might be the
performance aspect to consider, if autoclaim is lazily used on all
transactions (though, without autorelease, the impact would be minimal,
as actual claiming would occur only once).

Although you could use autorelease in conjunction with every occurrence
of autoclaim, I think it makes more sense to use it only in situations
where the interface was autoclaimed without actually being used -- such
as in a set-config call. In cases like this, even if the program knew
an interface was claimed, it wouldn't know _which_ interface was
claimed. Hence it wouldn't be able to release the interface manually
if it wanted to.

In other cases, where the interface _was_ used after the autoclaim, you
can logically require the program to do its own releasing. Or if the
program doesn't do a manual release and thereby causes trouble, you can
reasonably argue that it wasn't libusb's fault.

Alan Stern

[Pete Batard]

All,

I have now added auto-release to the Windows backend, and left
auto-claim enabled by default, since I am under the impression that the
majority here (myself included) sees more benefits in leaving autoclaim
in (as long as we have auto-release).

This was a bit more tricky than anticipated, as concurrency needs to be
factored it (making sure that if thread A and B are doing async control
requests on the same interface, we don't auto-release the interface
until both threads are done), and to keep things simple in the code, I
chose to apply auto-claim and auto-release on all control requests
rather than just set-config.

Again, since the first release is meant to be experimental and generate
feedback as to what works and what doesn't, I don't see the use of
autoclaim in the first release as that much of an issue, even if we have
to tweak it in subsequent release.

Regards,

/Pete