Closed tresf closed 3 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.
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 currentdevelop
branch.
Had a near-identical issue with RISC-V. The workaround was to simply copy this header into the work directory.
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.
Looks like recent PRs have fixed this (see #143)
Running
./build-hidapi.sh linux-armel
results in an error.Furthemore, the toolchain seems to be wrong:
hf
suffixgcc-arm-linux-gnueabihf
should begcc-arm-linux-gnueabi
--host=arm-linux-gnueabihf
should be--host=arm-linux-gnueabi
libudev-dev:armhf
should belibudev-dev:armel
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. 😆