Link local libusb statically on Linux/Mac

[xlz]

Following discussions in #281.

This builds libusb-1.0.a into libfreenect2.so.

An issue with that is libfreenect2.so will export symbols that belong to libusb-1.0, then the users can't link libfreenect2 with anything that links with the system libusb-1.0 (symbol conflicts).

This works around the above issue by using GCC linker flag --exclude-libs,libusb-1.0.a. On Mac OSX, ld64 does not support such operation, with only one solution: generate all symbols, remove _libusb_* symbols, and specify non-libusb symbols with -exported_symbols_list,nolibusb.sym.

If anyone has better approach, please comment below. Static linking on Windows is a seperate PR.

[xlz]

@tikiking1 Does this PR work for your libfreenect2-git and pyfreenect2? Do they work correctly with static libusb?

[remexre]

The Arch package builds fine, I'm updating it now. I don't actually have a Kinect 2 with me right now, but Protonect doesn't immediately segfault, so that's encouraging.

[remexre]

And pyfreenect2 builds fine, but gets ImportError: /usr/lib/libfreenect2.so: undefined symbol: udev_device_get_devnode when I actually import it. Adding udev to the libraries section of setup.py doesn't fix it. It's a mystery?

[xlz]

It's a bug. Thanks for the catch.

[xlz]

The bug was caused by reversing the link order of libusb. Can you update and try again?

(The reason this bug was not detected by running Protonect is because Protonect pulled in libudev via some other libraries, while libfreenect2.so itself did not.)

[remexre]

OK, it works now (in terms of getting an error because I don't have a Kinect with me, rather than because of a linking issue)

[remexre]

Is there a timeline for when this and #284 will get merged?

[floe]

Not really, although I'm hoping I'll get around to it sometime next week. Problem is that there may still be some interference with #292.

[xlz]

#292 is fairly easy to code up. The issue is a decision has to be made.

[xlz]

I start to think embedded static libusb in libfreenect2 is a bad idea. The hack of messing with export symbols was not a good idea from the outset and can easily break. Besides, it is really not up to libfreenect2 to decide where to install libusb, or to embed it.

For packagers, I think the best option is to carry a separate libusb.so in a private directory of the package you want to release and change RPATH of libfreenect2 to that directory. chrpath can do that job post hoc. If you know the install directory before building, -DCMAKE_INSTALL_RPATH=... will do that too (not right now; need a quick patch).

[xlz]

I have created a patch for specifying custom RPATH https://github.com/xlz/libfreenect2/commit/7a4708fa03d528ff9339c2c7034515e44861561a. It is expected to be part of a future PR soon.