search

luxonis / XLink

A cross-platform library for communicating with devices over various physical links.
Apache License 2.0
11 stars 17 forks source link

Device search improvements and libusb dependency #42

Closed themarpe closed 2 years ago

themarpe commented 2 years ago

Closes: #10

TODO:

themarpe commented 2 years ago

@wstnturner MinGW is currently broken because of libusb - if you are up for it, do you mind giving it a check and try compiling it with MinGW? https://github.com/luxonis/libusb branch cmake-android
Some (maybe relevant) info: https://github.com/libusb/libusb/issues/695#issuecomment-817326633

wstnturner commented 2 years ago

@wstnturner MinGW is currently broken because of libusb - if you are up for it, do you mind giving it a check and try compiling it with MinGW? https://github.com/luxonis/libusb branch cmake-android Some (maybe relevant) info: libusb/libusb#695 (comment)

Looks like there were a couple issues, one preventing successful configuration (libusb config.h was only generated for MSVC on Windows). That should be addressed by: https://github.com/luxonis/libusb/pull/2 . The other issue was more tricky, adjusting the include ordering of the libusb library header file (moving it above the XLink platform includes) resolved some kind of platform definition error. This should be resolved with: https://github.com/luxonis/XLink/pull/43

wstnturner commented 2 years ago

I'm curious what the plan is regarding a custom libusb dependency. Are the changes being made to support this branch going to be fed back into upstream? What about licensing considerations, it seems like static linking would force this XLink to LGPL. Also I noticed when building this branch on linux (Ubuntu (WSL)) using the hunter provided libusb dependency and a dynamic linking configuration -D BUILD_SHARED_LIBS=ON I get a couple link errors (relocation R_X86_64_TPOFF32/R_X86_64_PC32 against <symbol> can not be used when making a shared object; recompile with -fPIC). To be fair, it could be due to WSL.

themarpe commented 2 years ago

Thanks @wstnturner Going through it now...

Are the changes being made to support this branch going to be fed back into upstream?

Partially... the required changes for Android are will most likely be added as part of https://github.com/libusb/libusb/pull/874

What about licensing considerations, it seems like static linking would force this XLink to LGPL.

See: https://github.com/luxonis/XLink/issues/35#issuecomment-1007131283 and https://github.com/luxonis/XLink/issues/37 We'll default to shared library for libusb, so one can still statically link with XLink afterwards and not "pollute" downstream dependencies. In the end of the day, this default configuration will be exactly the same as installing libusb development package and linking to it. (as is done now for macOS and Linux)

Also I noticed when building this branch on linux (Ubuntu (WSL)) using the hunter provided libusb dependency and a dynamic linking configuration -D BUILD_SHARED_LIBS=ON I get a couple link errors (relocation R_X86_64_TPOFF32/R_X86_64_PC32 against can not be used when making a shared object; recompile with -fPIC). To be fair, it could be due to WSL.

Hunter limitation, -fPIC flag isn't properly detected and same "toolchain id" is being used (See: https://github.com/cpp-pm/hunter/issues/206, didn't have time to fix it...) - To resolve, clear cache when switching between shared and static build (rm -r ~/.hunter) or use a separate -D HUNTER_ROOT=[build/.hunter] when building for either.

themarpe commented 2 years ago

Merged both and updated this branch - all checks pass! Thanks @wstnturner !