gary-rowe / hid4java

A cross-platform Java Native Access (JNA) wrapper for the libusb/hidapi library. Works out of the box on Windows/Mac/Linux.
MIT License
223 stars 70 forks source link

Linux build linux-armel is failing #119

Closed tresf closed 3 months ago

tresf commented 2 years ago

Running ./build-hidapi.sh linux-armel results in an error.

Furthemore, the toolchain seems to be wrong:

I attempted to fix this by hand, but after a few unsuccessful builds dockcross is telling me You don't have enough free space in /var/cache/apt/archives/., which I can't figure out how to fix. 😆

gary-rowe commented 1 year ago

As an update I've taken a look at this problem recently and the problem remains. There seems to be no good way to get the build to install /usr/includes/libudev.h.

I'll leave this issue open as it's presently causing the linux-armel support to be missing in the current develop branch.

tresf commented 8 months ago

As an update I've taken a look at this problem recently and the problem remains. There seems to be no good way to get the build to install /usr/includes/libudev.h.

I'll leave this issue open as it's presently causing the linux-armel support to be missing in the current develop branch.

Had a near-identical issue with RISC-V. The workaround was to simply copy this header into the work directory.

https://github.com/gary-rowe/hid4java/blob/c65bfd1a5250305b93dd165fc6e3bc027649c563/build-hidapi.sh#L317

Now, I can't prove this theory, but I believe the cross-compilers are deliberately avoiding importing headers from the /usr/include due some some sysroot assumptions. The reason I believe this is because on the RISC-V branch, I had explicitly added -I/usr/include to the INCLUDES automake variable and saw it with make V=1, but still received the same error.

In the case of RISC-V (and I assume also this bug), the multilib package didn't install a prefixed version of the header, so when pkg-config reports the include directory, it's silently (and confusingly) ignored.

gary-rowe commented 3 months ago

Looks like recent PRs have fixed this (see #143)