You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I'm trying to compile a project (cyme) with udev and the 'hwdb' feature.
The project fails to compile when using cross ... --target aarch64-unknown-linux-gnu due to libudev-sys not including the ffi for hwdb because it can't find/call the udev_hwdb_* functions: 'udev-rs' then fails to compile due to this with the 'hwdb' feature enabled: Smithay/udev-rs#23
See https://github.com/tuna-f1sh/cyme/actions/runs/6906556985/job/18791852745 for failing build output. I can fix this with a 'udev_hwdb' feature but I'm wondering if it's possible to achieve this cross build and why cross fails to call that method. It works fine for the native container cross ... --target x86_64-unknown-linux-gnu.
Note that it's not due the to pkg-config setup referenced in the libudev-sys README: I've checked with docker run --rm -it cross-custom-cyme:aarch64-unknown-linux-gnu-5888d-pre-build /bin/bash that:
I'm using colima with a colima start --profile amd64 --cpu 4 --memory 8 --arch amd64 VM locally but the shared action shows this fails on Linux with docker so I've ticked that too.
Is it simply because libudev-sys is trying to call a aarch64 lib in the x86_64 container and so not really fixable without changes to that lib?
What target(s) are you cross-compiling for?
aarch64-unknown-linux-gnu
Which operating system is the host (e.g computer cross is on) running?
This is not a cross issue, rather it's libudev-syss build script doing false assumptions.
The assumptions it does wrong is that it assumes that the target = host, that the linker = default, and that the library lives in the default link paths.
The fix for this is simple, don't make those assumptions and correctly set linker, link paths and target
Ah I thought it might be a lib issue rather than cross - thanks for the proactive reply and fix.
I can confirm your patch fixes the aarch64 target but I now encountered an issue for the native build. I've replied in dcuddeback/libudev-sys#16. Still not a cross issue however.
Checklist
Describe your issue
I'm trying to compile a project (cyme) with udev and the 'hwdb' feature.
The project fails to compile when using
cross ... --target aarch64-unknown-linux-gnu
due to libudev-sys not including the ffi for hwdb because it can't find/call theudev_hwdb_*
functions: 'udev-rs' then fails to compile due to this with the 'hwdb' feature enabled: Smithay/udev-rs#23See https://github.com/tuna-f1sh/cyme/actions/runs/6906556985/job/18791852745 for failing build output. I can fix this with a 'udev_hwdb' feature but I'm wondering if it's possible to achieve this cross build and why cross fails to call that method. It works fine for the native container
cross ... --target x86_64-unknown-linux-gnu
.Note that it's not due the to pkg-config setup referenced in the libudev-sys README: I've checked with
docker run --rm -it cross-custom-cyme:aarch64-unknown-linux-gnu-5888d-pre-build /bin/bash
that:Also tried even installing
udev:aarch64
and that:I've made a project to reproduce this issue: https://github.com/tuna-f1sh/cross-udev-hwdb
I'm using colima with a
colima start --profile amd64 --cpu 4 --memory 8 --arch amd64
VM locally but the shared action shows this fails on Linux with docker so I've ticked that too.Is it simply because libudev-sys is trying to call a aarch64 lib in the x86_64 container and so not really fixable without changes to that lib?
What target(s) are you cross-compiling for?
aarch64-unknown-linux-gnu
Which operating system is the host (e.g computer cross is on) running?
What architecture is the host?
What container engine is cross using?
cross version
cross 0.2.5
Example
Checkout: https://github.com/tuna-f1sh/cross-udev-hwdb
cross build --locked --release --all-features --target=aarch64-unknown-linux-gnu --target-dir build
Additional information / notes
No response
The text was updated successfully, but these errors were encountered: