Change:
<ins> --- a/tools/nut-scanner/nutscan-init.c +++ b/tools/nut-scanner/nutscan-init.c @@ -44,6 +44,10 @@ int nutscan_load_upsclient_library(const char *libname_path); /* FIXME: would be good to get more from /etc/ld.so.conf[.d] */ char * search_paths[] = { +	"@avahi@", +	"@freeipmi@", +	"@libusb@", +	"@neon@", LIBDIR, "/usr/lib64", "/lib64", </ins>

Discussion:
Describe the bug Network UPS Tools (), ships a binary to enumerate currently connected power devices. On my system looks for libraries like in hardcoded paths like and fails to find them. I see that the package wraps the binary to override with correct values, but loads these libraries manually with and doesn't seem to respect . To Reproduce Expected behavior should be able to load libraries at runtime from dependencies like . Additional information As a quick and dirty test, I to my systemPackages, an overlay to a local copy of the nut source... ... and directly patched the nut-scanner source to look in . This allowed to find and proceed with USB support. I'm not sure what the proper fix would be though. Notify maintainers CC Metadata Please run and paste the result.
I quickly googled for , and found , which seems to suggest it honors . However, setting in a wrapper is discouraged, as it propagates through to binaries executed by the wrapped binary. As we build from source here, any chance we could get the build system to add these paths to the binaries' ? Otherwise, you probbaly should use patchelf to do that, instead of wrapping.
LTDLLIBRARYPATH doesn't seem to work either. The GNU docs state that "If filename is not an absolute path...", and nut-scanner constructs absolute paths based on the prefixes below:
brr, I don't understand why they implemented their own dynamic linker. I'd propose reaching out to upstream, if some of that behaviour can be changed - otherwise, we could ship a patch downstream in nixpkgs, replacing some of the paths with dependencies (patch replacing with placeholder, before applying, like done in the derivation)
Yeah it's strange that they did it this way, especially since libtool provides an ltdladdsearchdir() function that I think would take care of all this. There's one other nix-related thing I don't understand. I modified the nut-scanner source to look for "libusb-" (with no leading directory) which now allows libtool to automatically search LDLIBRARY_PATH. However, it still doesn't find anything. It only works if I use "libusb-" instead. Looking at the contents of the libusb derivation, it indeed doesn't have any "libusb- -libusb-" symlinks. any idea how I can handle this cleanly? Thanks in advance.

I think these links symlinks don't matter too much if build systems ask pkg-config about which library to link against. For : This means it'll look for .
This probably won't help us here, though - we can't really reuse the output of to update the patches. Can you get their build system to discover things with pkgconfig? Otherwise, probably just hardcoding (and waiting for it to break again) might be fine. In any case, I'd encourage opening an issue upstream. Not honoring , etc. and instead just writing your own logic sounds like a bug to me.
Okay, sorry for the delay. I just opened with upstream.
I marked this as stale due to inactivity. &rarr;
This is still an issue: And I guess the maintainers do not want to support . So what are some other options?
Confirming this is still an issue
Can someone using this try and report back?
yes it works. Tracking the packaging update in .