Summary: | sys-power/nut-2.6.5-r1 with dev-libs/libusb-compat-0.1.5-r2 - nut-scanner -U: Cannot load USB library (libusb) : file not found. USB search disabled. | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Dirk Gouders <dirk> |
Component: | Current packages | Assignee: | Robin Johnson <robbat2> |
Status: | CONFIRMED --- | ||
Severity: | normal | CC: | garth, itumaykin+gentoo, jason+gentoobugs, luksan, msdobrescu, prometheanfire, titanofold, web |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | AMD64 | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: | nut-2.6.5-load_legacy_libusb_based_on_SONAME.patch |
Description
Dirk Gouders
2013-10-01 09:18:27 UTC
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. |