FS#30467 - [libusbx] fails to include needed symbols; not suitable replacement for libusb
Attached to Project:
Arch Linux
Opened by Jon Watte (jwatte) - Thursday, 28 June 2012, 05:32 GMT
Last edited by Tobias Powalowski (tpowa) - Tuesday, 03 July 2012, 09:59 GMT
Opened by Jon Watte (jwatte) - Thursday, 28 June 2012, 05:32 GMT
Last edited by Tobias Powalowski (tpowa) - Tuesday, 03 July 2012, 09:59 GMT
|
Details
Description:
Arch uses libusbx instead of libusb. Unfortunately, libusb.a doesn't contain all necessary symbols. Additional info: * package version(s) libusbx-1.0.12-1 * config and/or log files etc. Steps to reproduce: 1. pacman -Syu libusbx 2. Compile something with -I/usr/include/libusb-1.0 3. Link with -lusb 4. See failure to link with missing symbol libusb_init() (and a bunch of others). Attached is the output of "nm /usr/lib/libusb.a" -- note all the missing libusb_ symbols: There is apparently a lot of drama around libusb/libusbx, at least if you look at the Wiki of the fork libusbx. As it seems the main concern with libusb is "slow to release," but libusb latest release is 2012-04-24, perhaps the original is a suitable replacement if the fork isn't actually working. 
missing-symbols.txt
(9.5 KiB)
|
This task depends upon
It also shows that /all/ the documented libusb_ symbols are undefined
Congfiguring and installing libusb-1.0.9 (not x) produces a working lset of libraries.
Why is the lib called libusb.a and not libusb-1.0.a?
My hypothesis is that libusb.a comes from libusb-compat and is not
(statically) linked with libusb (or libusbx). So of course all the
libusb-1.0 symbols are missing.
Can you check that?
Another good idea is to NOT distribute a static lib. Only the dynamic
.so should be provided. But that is not the problem.
Bye