Description
Problem description
This crate has some side effect to my project build. I'm actually working on a project that links to a .so that is installed in a custom path, using pkg-config to get the correct -I/-L/-l flags.
But when I'm linking to evdev-rs, I get an extra -L/usr/lib/x86_64-linux-gnu before my own -L flag. In my specific case, I want to link to a new version of a library that is already available in standard installation paths. Because of the wrong -L order, the linker will try to use the wrong library version (and fails to link because I'm adding some new symbols).
It would be better to get rid of this -L/usr/lib/x86_64-linux-gnu, and let the linker search into my cargo:rustc-link-search at first, and then fallback to /usr/lib/x86_64-linux-gnu that is a standard research path.
Maybe there is a way to force the -L order, but I haven't found it.
Analysis
In build.rs, the call to pkg-config has a weird behavior.
I expected the flags to be configured like this:
-I/usr/include/libevdev-1.0/ -levdev
Instead, it does something else instead:
$ PKG_CONFIG_ALLOW_SYSTEM_LIBS=1 pkg-config --cflags --libs libevdev
-I/usr/include/libevdev-1.0/ -L/usr/lib/x86_64-linux-gnu -levdev
Someone has already complained long ago about this, but the default behavior hasn't been changed: rust-lang/pkg-config-rs#35. Instead, a configuration flag has been added to disable this behavior: rust-lang/pkg-config-rs@d184e48.
I made a test on my side with a print_system_libs(false), and it fixes my build issue.
Do you think it is possible to change this behavior in evdev-rs ?