Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 486640 - 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.
Summary: sys-power/nut-2.6.5-r1 with dev-libs/libusb-compat-0.1.5-r2 - nut-scanner -U:...
Status: CONFIRMED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: AMD64 Linux
: Normal normal with 1 vote (vote)
Assignee: Robin Johnson
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-10-01 09:18 UTC by Dirk Gouders
Modified: 2016-10-15 22:30 UTC (History)
4 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
nut-2.6.5-load_legacy_libusb_based_on_SONAME.patch (nut-2.6.5-load_legacy_libusb_based_on_SONAME.patch,485 bytes, patch)
2013-10-20 12:18 UTC, Samuli Suominen
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Dirk Gouders 2013-10-01 09:18:27 UTC
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"
Comment 1 Dirk Gouders 2013-10-01 13:21:38 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.
Comment 2 Samuli Suominen gentoo-dev 2013-10-20 11:55:26 UTC
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.
Comment 3 Samuli Suominen gentoo-dev 2013-10-20 12:18:38 UTC
Created attachment 361428 [details, diff]
nut-2.6.5-load_legacy_libusb_based_on_SONAME.patch

This is untested.
Comment 4 Dirk Gouders 2013-10-20 13:09:14 UTC
(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...
Comment 5 Robin Johnson archtester Gentoo Infrastructure gentoo-dev Security 2014-01-05 03:38:33 UTC
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.
Comment 6 Coacher 2014-01-05 17:52:32 UTC
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.
Comment 7 Robin Johnson archtester Gentoo Infrastructure gentoo-dev Security 2014-01-05 18:12:14 UTC
itumaykin:
Can you please open that in a new bug? My APC SU1400 does work w/ the USB HID driver still.
Comment 8 Coacher 2014-01-05 19:52:22 UTC
(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
Comment 9 Robin Johnson archtester Gentoo Infrastructure gentoo-dev Security 2014-01-05 20:43:51 UTC
I've got a partial fix in the tree, but waiting for any response on -dev before considering changing gen_ld_script.
Comment 10 Matthew Thode ( prometheanfire ) archtester Gentoo Infrastructure gentoo-dev Security 2014-02-17 06:35:00 UTC
you get that response?
Comment 11 Garth 2015-05-06 06:17:29 UTC
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.
Comment 12 Ciprian Ciubotariu 2016-10-15 22:30:03 UTC
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?