nut's USB interface is not available with libusb-compat-0.1.5-r2: # nut-scanner -U Cannot load USB library (libusb) : file not found. USB search disabled. I inspected that problem with strace(1) and nut reads /usr/lib/libusb.so but then outputs the error message: ... access("/lib/libusb.so", R_OK) = -1 ENOENT (No such file or directory) access("/usr/lib/libusb.so", R_OK) = 0 futex(0x7f6bc06660c8, FUTEX_WAKE_PRIVATE, 2147483647) = 0 open("/usr/lib/libusb.so", O_RDONLY|O_CLOEXEC) = 3 read(3, "/* GNU ld script\n Since Gentoo"..., 832) = 529 close(3) = 0 write(2, "Cannot load USB library (libusb)"..., 72) = 72 ... Because nut first searches for that file in /lib/, I created a symbolic link there: # cd /lib64/ # ln -s libusb-0.1.so.4.4.4 libusb.so This bypasses the linker script in /usr/lib/ and makes nut happy: # nut-scanner -U Scanning USB bus. [nutdev1] driver = "usbhid-ups" port = "auto" vendorid = "051D" productid = "0002" product = "Smart-UPS 3000 RM FW:666.6.I USB FW:7.3" serial = "JS0750018169" vendor = "American Power Conversion" bus = "002"
Some more information: The function that returns the error is lt_dlopenext() called in tools/nut-scanner/scan_usb.c:61. So, I seems it is libtool that does not understand linker script /usr/lib/libusb.so.
In nut source tree at file tools/nut-scanner/scan_usb.c there is a line: static char * libname = "libusb"; And down the same file there is: dl_handle = lt_dlopenext(libname); Therefore we should fix it to point to the actual SONAME instead of relying on the linker script. I don't know if something like this would work: static char * libname = "libusb-0.1"; Or: static char * libname = "libusb-0.1.so.4"; Someone with better libtool and C knowledge can propably write a quick patch. I'm just pointing to right direction. Thanks.
Created attachment 361428 [details, diff] nut-2.6.5-load_legacy_libusb_based_on_SONAME.patch This is untested.
(In reply to Samuli Suominen from comment #3) > Created attachment 361428 [details, diff] [details, diff] > nut-2.6.5-load_legacy_libusb_based_on_SONAME.patch > > This is untested. Tested your patch but it doesn't help, because /usr/lib/libusb-1.0.so is identical to libusb.so: a linker script that is not understood. Here is the output of nut-scanner: # nut-scanner -U Cannot load USB library (libusb-0.1) : file not found. USB search disabled. nut-scanner : detecting available power devices. [SNIP] What is needed is a way that the .so file is searched for in /lib prior to /usr/lib or that libtool (the function lt_dlopenext()) understands the linker script in /usr/lib...
I tried fixing it myself, but after making it work for skipping the linker scripts by using lt_dlforeachfile and a callback that tests each libusb, I found there is a deeper problem: gen_ld_script seems to be removing the original base .so, and lt_dlopenext only looks for a suffix of .so. I'm going to raise the issue on -dev because I think it may affect many more packages.
I would like to mention that not only nut-scanner is broken, but also some drivers stopped working, for example blazer_usb. So, this is a major problem for sys-power/nut as a whole.
itumaykin: Can you please open that in a new bug? My APC SU1400 does work w/ the USB HID driver still.
(In reply to Robin Johnson from comment #7) > itumaykin: > Can you please open that in a new bug? My APC SU1400 does work w/ the USB > HID driver still. Here it is https://bugs.gentoo.org/show_bug.cgi?id=497170
I've got a partial fix in the tree, but waiting for any response on -dev before considering changing gen_ld_script.
you get that response?
This is still happening with sys-power/nut-2.7.2-r2 . However, instead of looking for libusb.so, it is now looking for: libusb-0.1.so So it is now aware of the two different libusb, but dev-libs/libusb-compat (using stable version 0.1.5-r2 ) only create libusb-0.1.so.4.4.4 & symlink libusb-0.1.so.4 to it. A quick workaround is to: ln -s /lib64/libusb-0.1.so.4.4.4 /lib64/libusb-0.1.so A proper fix should however be implemented, either having libusb-compat create a libusb-0.1.so symlink, or having nut look for libusb-0.1.so.4 or libusb-0.1.so.4.4.4 , unfortunatly I'm not knowledgable enough to generate such a fix.
The ebuild patch ${PN}-2.7.1-fix-scanning.patch seems to be changing the name from libusb to libusb-0.1. See the following change: -static char * libname = "libusb"; +static char * libname = "libusb-0.1"; Maybe this can help fixing the USB without affecting other packages. I tried it but didn't work. I thought I'd mention this though, perhaps it will help others. However, by looking at commit https://github.com/networkupstools/nut/commit/75c6e065574dfea99c2221664e1778252b69e902, this was solved upstream in 2.7.4. I've made an ebuild following nut-2.7.3 from portage, and it works just fine: pink ~ # nut-scanner Scanning USB bus. Scanning XML/HTTP bus. No start IP, skipping NUT bus (old connect method) [nutdev1] driver = "blazer_usb" port = "auto" vendorid = "0665" productid = "5161" product = "USB to Serial" vendor = "INNO TECH" bus = "001" You'll find my ebuild at https://github.com/CMoH/portage-overlay/tree/master/sys-power/nut. Can we expect a version bump in the main portage tree?
Still happening for 2.8.0-r2: Cannot load USB library (/usr/lib64/libusb-1.0.so) : file not found. USB search disabled. The file exists on the path.
Can confirm bug still present with sys-power/nut-2.8.0-r2. ``` # nut-scanner -U Cannot load USB library (/usr/lib64/libusb-1.0.so) : file not found. USB search disabled. .... ``` HACK: ``` # mv /usr/lib64/libusb-1.0.so /usr/lib64-1.0.so.bak # ln -s /lib64/libusb-1.0.so.0.3.0 /usr/lib64/libusb-1.0.so # nut-scanner -U Scanning USB bus. [nutdev1] ... # ```
(In reply to Jason Cooper from comment #14) > Can confirm bug still present with sys-power/nut-2.8.0-r2. > > ``` > # nut-scanner -U > Cannot load USB library (/usr/lib64/libusb-1.0.so) : file not found. USB > search disabled. > .... > ``` > > HACK: > > ``` > # mv /usr/lib64/libusb-1.0.so /usr/lib64-1.0.so.bak > # ln -s /lib64/libusb-1.0.so.0.3.0 /usr/lib64/libusb-1.0.so > # nut-scanner -U > Scanning USB bus. > [nutdev1] > ... > # > ``` This worked for me.
