Created attachment 631130 [details, diff] Fix for meson.build with older kernel headers. The meson based build of dev-libs/libevdev-1.9.0 fails when using sys-kernel/linux-headers-4.14-r1. The library builds OK but the build goes on to fail on the tools with the following error ../libevdev-1.9.0/tools/libevdev-events.c: In function â: ../libevdev-1.9.0/tools/libevdev-events.c:115:7: error: â has no member named â ev->input_event_sec, ^~ ../libevdev-1.9.0/tools/libevdev-events.c:116:7: error: â has no member named â ev->input_event_usec, ^~ ../libevdev-1.9.0/tools/libevdev-events.c:120:6: error: â has no member named â ev->input_event_sec, ^~ ../libevdev-1.9.0/tools/libevdev-events.c:121:6: error: â has no member named â ev->input_event_usec, As this code has not changed between 1.8 and 1.9 I checked things out and found that the library is OK because the code uses its own copy of the relevant kernel headers. The meson build only uses the headers for the library build and not the tools like the old build did. The included patch modified meson.build to use these headers when building the tools that need them.
Thanks. Could you open a pull request upstream in https://gitlab.freedesktop.org/libevdev/libevdev ?
(In reply to Matt Turner from comment #1) > Thanks. Could you open a pull request upstream in > https://gitlab.freedesktop.org/libevdev/libevdev ? No?
Hey there! I don't think this problem has been fixed in Gentoo yet. When I emerge libevdev-1.9.0, I'm still getting the compilation error: ../libevdev-1.9.0/tools/libevdev-events.c: In function 'print_event': ../libevdev-1.9.0/tools/libevdev-events.c:115:7: error: 'struct input_event' has no member named 'input_event_sec' 115 | ev->input_event_sec, | ^~ It looks like the patch has been submitted upstream (https://lists.freedesktop.org/archives/input-tools/2020-March/001532.html), but it did NOT make it into the 1.9.0 release. Could you include the patch in the ebuild until the next release of libevdev? Thanks!
I too am still seeing this build failure. Can attach build.log or any other info that will help, but it sounds like the problem has been debugged and the fix need only be applied.
A simpler fix may be to make a newer sys-kernel/linux-headers a dependency of this package in portage. Regardless, this bug's current status of RESOLVED does not accurately reflect its status in gentoo.
