python-libusb1 icon indicating copy to clipboard operation
python-libusb1 copied to clipboard

OSError: dlopen failed: library "libusb-1.0.so" not found

Open Camcz opened this issue 4 years ago • 11 comments

Hello, I am building an app using Kivy. When running the app in android using buildozer android run logcat I get the error:

.../.buildozer/android/platform/build-arm64-v8a/build/python-installs/myapp/usb1/libusb1.py", line 157, in _loadLibrary
.../.buildozer/android/platform/build-arm64-v8a/build/other_builds/python3/arm64-v8a__ndk_target_21/python3/Lib/ctypes/__init__.py", line 373, in __init__
09-10 00:28:32.415  9400  9428 I python  :  OSError: dlopen failed: library "libusb-1.0.so" not found
09-10 00:28:32.415  9400  9428 I python  : Python for android ended.

When looking at the libusb1.py file, in the _loadLibrary function I see that my system 'Linux' is not catered for, hence the error (I stand to be corrected).

I thought of creating a recipe so I could edit the libusb1.py file and add the path to the libusb-1.0.so.0 in my computer which is '/lib/x86_64-linux-gnu/libusb-1.so.0' but that is something I do not know since I am new to app development using Kivy and buildozer.

If there are any workarounds for this kind of issue, please help.

Camcz avatar Sep 10 '21 11:09 Camcz

Hello and thanks for the report.

About _loadLibrary, the general intent is to first try to let the OS linker find the library to load, and only if it fails to apply platform-specific workarounds for common library locations.

So the ideal fix would be to somehow get libusb-1.0.so to become reachable by the linker. I have no experience of this level with android. Is it present in android at all ? Otherwise, I guess this means each application needs to bundle its own copy of it. Also, I note that the logcat output mentions arm64: you will need to bundle a libusb built for the correct architecture, x86_64 would likely fail with exactly the same error. Then you will need to figure out where the linker will be able to find the library.

On this last point, I have just pushed a proof-of-concept change to allow programs to give usb1.USBContext a library to use, allowing the program to get full control of the library lookup logic. It is not ready for release, but ideas and feedback is very welcome. More discussion about this happen in #37 . The code is in the wip branch.

vpelletier avatar Sep 10 '21 14:09 vpelletier

Checking libusb usage on android, it looks like there are a few more roadblocks:

  • libusb_wrap_sys_device is not accessible via python-libusb1
  • to be able to call libusb_wrap_sys_device, libusb_set_option may be needed, and this function cannot be safely used via ctypes because it uses a variadic (see #75 )

For the first point, the difficulty is going to be the lifecycle reversal: normally, USBDevice outlives USBDeviceHandle, but not in this case: libusb_close (closing the handle) also destroys the device.

vpelletier avatar Sep 10 '21 22:09 vpelletier

Take note libusb itself have multiple issues under Android (non rooted device).

Possible now: https://github.com/libusb/libusb/pull/830 (which is inline with the above comments) Next step: https://github.com/libusb/libusb/pull/874

I tried to get pyusb to work under Termux Android but failed: https://github.com/pyusb/pyusb/issues/285

mcuee avatar Sep 11 '21 01:09 mcuee

Next step: libusb/libusb#874

This looks very good. It looks like it would solve both of the above roadblocks.

vpelletier avatar Sep 11 '21 03:09 vpelletier