Dynamically load libudev in linux-hidraw backend

[falkTX]

This PR removes the direct build and link dependency on libudev from the Linux hidraw backend. The backend now loads libudev.so.1 at runtime, so applications that link hidapi do not inherit a direct libudev dependency. Systems using the hidraw backend still need the libudev runtime library.

Implementation

• Load libudev with a scoped RTLD_NOW | RTLD_LOCAL handle.
• Resolve the exact libudev entry points used by hidapi and report missing-library or missing-symbol failures through hid_error().
• Clear all resolved function pointers and close the handle on partial initialization failure and during hid_exit().
• Remove the included LGPL loader source and the libudev development/pkg-config dependency.
• Propagate the platform dynamic-loader library through CMake, Autotools, the manual Makefile, pkg-config, and installed static CMake exports.
• Update Linux documentation and CI to install runtime-only packages (libudev1 on Ubuntu and eudev-libs on Alpine).
• Add shared/static lifecycle tests for reloads, partial symbol-resolution failures, recovery, and balanced dlopen/dlclose cleanup.

Validation

• Strict-warning shared and static CMake builds and CTests.
• Shared ASAN CMake build and CTests.
• Full CMake build with both Linux backends.
• Fresh Autotools bootstrap/configure/build and distribution generation.
• Manual Makefile build.
• Installed static CMake consumer with libudev pkg-config metadata unavailable.

Assisted-by: codex:gpt-5.6-sol

[mcuee]

The build failed under Ubuntu and Arch Linux.

[falkTX]

The build failed under Ubuntu and Arch Linux.

Related to more strict warnings, likely fixed now.

[mcuee]

The build failed under Ubuntu and Arch Linux.

Related to more strict warnings, likely fixed now.

Not yet...

[falkTX]

The build failed under Ubuntu and Arch Linux.

Related to more strict warnings, likely fixed now.

Not yet...

I built locally with the same pedantic flags and pushed another try.

[Youw]

I don't mind the idea of having libudev loaded dynamically in runtime, but I can't agree that the current aproach is best for that. A few points I'd ask to change if I where to accept it this way:

• licence shouldn't derive from libudev license - we don't copy-paste their code, and HIDAPI uses a bit different licencing sceme, and the new source that becomes a part of HIDAPI would potentially restrict its users;
• including the .c file for this purpose looks a bit ugly, and the name libudev.c suggests that it actually is (i.e. implements) libudev, but in fact it is only a wrapper; what is best instead - have a hidapi_libudev_wrap.h, and all functions inside should be either static or inline;
• the C() macro... I checked - it is a valid C, but the fact that I had to go and double-check suggests that it looks like something that might break; HIDAPI_UDEV_RESOLVE wouldn't raise any naming suspicious
• RTLD_GLOBAL - that is a code smell to use it here, where passing the _lib (or rather udev_lib_handle to dlsym) explicitly is what I'd expect
• no dlclose which is technically a resource leak if HIDAPI itself is ever to be dynamically loaded

---

At the end of the day - I'd be much happier to see a more common way of dynamically loading a library during the initialisation, saving and using function pointers explicitly and unloading a library during the hid_exit, e.g. like we did it for windows backend.

Yes that would cause a lot more changes in linux/hid.c - but that's absolutely fine.

[falkTX]

That is all very fair, I mostly did this change as a way to get my cross-compilation builds working and decided to push it upstream because why not.

You have good points for something that would be integrated officially in hidapi, but sorry to say my needs are covered already as-is, the steps you mention make sense but sound like it would be quite a bit more work than I am willing to spend just for a small feature.

If you think the feature is worthwhile, take all the code here to adapt freely under any license, I give written consent.
This is as far as I go though, perhaps someone else can take over now.
Or otherwise feel free to close the PR too, I can understand that too.

[Youw]

Thanks for the contribution.

I'll leave it be for now, in case anyone wants to catch up.

[Youw]

Anyone care to try this out?

[mcuee]

Anyone care to try this out?

Just wondering how to properly test this PR. Thanks.

[Youw]

• Ensure no libudev-dev package is installed (so libudev.h is not available)
• Build locally from sources
• Run and verify that enumeration/etc. works as usual