The following is a questing from the Debian pkg-bitcoin-dev group and I am interested too:
If you are familiar, could you explain this? Why should we not be
using system libusb?
- Added yet more warnings suggesting not to use the system libusb in configure.
Debian Jessie and Unstable (SID) libusb
libusb-1.0-0 (2:1.0.19-1)
This is an annoying issue we've been dealing with for as long as we've been using libusb and the answer to your question is as frustrating as can be.
Libusb had a hostile fork a few years back with libusbx and the main libusb development had slowed to a crawl. Virtually every distribution eventually moved to libusbx simply because it was the more actively developed branch. However at the time we found that every time we tried to migrate to libusbx it added substantial instability to the devices we were communicating with as most asic usb miners were actually pretty hastily slapped together and not very tolerant. Kano did a lot of investigation and found that there were numerous occasions where sending timeout based requests to libusb it simply would not return. The issue was amplified on windows and almost universal on usb1.1 devices which unfortunately many asic manufacturers decided to use (despite being a 15 year old protocol instead of usb2). Eventually the development of libusb was stopped and there was an alleged merge between the libusbx and libusb code and libusbx inherited the original libusb name with what appears to have been a somewhat strained truce between the original libusb developer and the libusbx devs. Unfortunately what happened was they built on the libusbx code and it appears that whatever it was that made the original libusb more stable never made it back into the maintained branch. We ended up finding the end of life libusb that we were using was still the most stable and none of the extra features in the newer libusbx based code were of any advantage and it conferred more instability. Here is the last time I tried moving to the merged libusbs:
https://bitcointalksearch.org/topic/m.4816354If you follow the few pages of testing (and ignore the pages of trolling) you'll see how I end up giving up on libusbx again.
And here is where I reverted to our own included libusb code :
https://bitcointalksearch.org/topic/m.4989440The same problems still exist with the current libusb included in distributions.
Now you're probably saying we should have submitted bug reports to libusbx instead of including libusb however we spent a ridiculous amount of time trying to find where the problem was in the first place and asic driver development was nothing short of
frantic at the time and the amount of time we spent on it was far in excess of what we wanted already and it was detracting from further cgminer and driver development so I gave up and stuck to the libusb we included since it basically worked and was stable - what else can one ask? It also was not clear which was the real libusb... You'll also see that I was dependent on users to do the testing since I wasn't the one reproducing the problems so I couldn't do any cycle of test and report upstream. I doubt you'll be able to get any of those users with the old hardware engaged in that cycle of discussion now with libusb devs.
EDIT: Here's where Kano first tracked down the problem:
https://bitcointalk.org/index.php?topic=28402.msg2948402;topicseen#msg2948402https://bitcointalk.org/index.php?topic=28402.msg2970018;topicseen#msg2970018Adding the --with-system-libusb was put there for platforms where there was no udev support and building would fail (eg openwrt) forcing them to use the system libusb instead of the included one. However I've since added a --disable-udev option which makes it build even there. If I removed the system-libusb option and silently built my own included libusb for the packagers they'd be none the wiser.
