Why patch libusb?

[remexre]

Simply put, why is libusb being patched? On Arch Linux, with libusb 1.0.19, Protonect encounters bug #182 after the original build tree (in /tmp) is deleted. On the same Arch Linux, requiring patched libraries is generally frowned upon.

[gaborpapp]

according to readme.depends.txt it increases MAX_ISO_BUFFER_LENGTH, which is required for kinect2 to work as far as I know:

kernel 3.10+
libusbx 1.0.17
with superspeed patch by Joshua Blake joshblake@gmail.com see https://github.com/JoshBlake/libusbx/tree/superspeed
with MAX_ISO_BUFFER_LENGTH increased to 49152 in libusb/os/libusb_usbfs.h

[floe]

Right now, there is no stable/release version of libusb which works. The superspeed patch is already part of the official tree, but later changes in 1.0.19 messed things up again, so we simply checkout libusb-1.0 commit 51b10191033ca3a3819dcf46e1da2465b99497c2 which is known to work and build that.

Not ideal, and more or less a showstopper for "official" distribution packages, but unless someone manages to make libusb master work and integrates the required changes in libusb and creates a new release, there's not much we can do about it IMHO.

[remexre]

So, I'm asking as the maintainer of the Arch Linux libfreenect2-git AUR package. What do you think the best way to distribute libfreenect2 is? I think maybe putting the patched libusb in /usr/lib/libfreenect2/libusb-1.0.so.0 would do it? Can you foresee any major problems from doing that?

[remexre]

Okay, I just tried it, and ldd reports both /usr/bin/Protonect and pyfreenect2's _pyfreenect.so using the patched version.

[floe]

Now that I've been thinking about this for a little more, we should consider simply statically linking to our patched libusb-1.0 - then the whole rpath mess would be avoided? /cc @xlz @larshg

[xlz]

Yes.

[floe]

OK, in theory, this would involve only one thing, and that is changing LibUSB_LIBRARIES in CMakeLists.txt to LibUSB_STATIC_LIBRARIES. I've just tried that, and it doesn't have any noticeable effect :-/

Manually adding libusb-1.0.a didn't work either, unfortunately, because that (correctly) triggers the following error:

/usr/bin/ld: /.../libusb-1.0.a(libusb_1_0_la-core.o): relocation R_X86_64_32 against `.rodata.str1.1' can not be used when making a shared object; recompile with -fPIC
/.../libusb-1.0.a: error adding symbols: Bad value

So for this to work, the static libusb-1.0 library would need to be compiled as PIC, which makes sense, as we want to re-create a shared object from that code...