nut-scanner не находит библиотеку

ну если там аски-текст, то видимо как библиотека не подгрузиццо.

Нормальный бинарник — в другой директории, /lib64 вместо /usr/lib64. Как заставить искать его там?

Что за кашу ты написал? Может быть ты и проверял нормально, но из темы это не видно.

Сделай:

file /usr/lib*/libusb-1*
file /lib*/libusb-1*
ls -al / | grep lib
cat /usr/lib64/libusb-1.0.so 

С LD_LIBRARY_PATH всё максимально нелепо: во-первых, это опция для линкера, а не для самой проги, во-вторых, прога ищет libusb-1.0.so, ты ей подсовываешь /lib64 но в наличии /lib64/libusb-1.0.so не убедился (команды выше это сделают).

а что говорит ldd на nut-scanner? я так понимаю, он не собирался под гентой?

ldd тут ни при чём, это ручной dlopen().

Если б оно не грузилось линкером то ошибка была бы другая и точно ничего про «usb search disabled» не было бы.

уел.

в наличии /lib64/libusb-1.0.so не убедился

Спасибо, уже обнаружил, что его не существует. Ни один пакет его не ставит. /lib64/libusb-1.0.so.0 и /lib64/libusb-1.0.so.0.3.0 есть.

Но даже если создать ссылку ln -s /lib64/libusb-1.0.so.0.3.0 /lib64/libusb-1.0.so, nut-scanner пытается запускать /usr/lib64/libusb-1.0.so.

$ file /{,usr/}lib*/libusb-1*
/lib64/libusb-1.0.so:         symbolic link to /lib64/libusb-1.0.so.0.3.0
/lib64/libusb-1.0.so.0:       symbolic link to libusb-1.0.so.0.3.0
/lib64/libusb-1.0.so.0.3.0:   ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, stripped
/usr/lib64/libusb-1.0.so:     ASCII text
/usr/lib/libusb-1.0.so:       symbolic link to libusb-1.0.so.0.3.0
/usr/lib/libusb-1.0.so.0:     symbolic link to libusb-1.0.so.0.3.0
/usr/lib/libusb-1.0.so.0.3.0: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), dynamically linked, stripped

$ cat /usr/lib64/libusb-1.0.so 
/* GNU ld script
   Since Gentoo has critical dynamic libraries in /lib, and the static versions
   in /usr/lib, we need to have a "fake" dynamic lib in /usr/lib, otherwise we
   run into linking problems.  This "fake" dynamic lib is a linker script that
   redirects the linker to the real lib.  And yes, this works in the cross-
   compiling scenario as the sysroot-ed linker will prepend the real path.

   See bug https://bugs.gentoo.org/4411 for more info.
 */
OUTPUT_FORMAT ( elf64-x86-64 )
GROUP ( /lib64/libusb-1.0.so.0 )

а что говорит ldd на nut-scanner?

$ ldd /usr/bin/nut-scanner
        linux-vdso.so.1 (0x00007ffdc01c4000)
        libnutscan.so.2 => /usr/lib64/libnutscan.so.2 (0x00007f5ec6cc0000)
        libc.so.6 => /lib64/libc.so.6 (0x00007f5ec6ae8000)
        libltdl.so.7 => //usr/lib64/libltdl.so.7 (0x00007f5ec6ad8000)
        libssl.so.3 => //usr/lib64/libssl.so.3 (0x00007f5ec6a30000)
        libcrypto.so.3 => //usr/lib64/libcrypto.so.3 (0x00007f5ec6600000)
        /lib64/ld-linux-x86-64.so.2 (0x00007f5ec6d28000)
        libz.so.1 => /usr/lib64/libz.so.1 (0x00007f5ec65e0000)

я так понимаю, он не собирался под гентой?

Собирался. Только что.

https://bugs.gentoo.org/486640
https://bugs.gentoo.org/836776

Похоже мэйнтэйнеру надо патчить nut

Maintainer:  None specified

А... Пичалька :-(

Там кажется немного другое хотя и с похожей ошибкой. А может и то же самое.

Странно, судя по содержимому файла он должен правильно редиректить на нужную библиотеку.

Ну, тут можно две вещи сделать:

1. запустить с strace и посмотреть какой на самом деле файл он не может найти

2. временно убрать этот текстовый файл, заменить на симлинк к библиотеке и посмотреть что будет

Второй вариант, даже если заработает, не даст наверно полного понимания проблемы, а так же не очень хорошо наверно оставлять систему в таком виде, но, возможно, что-нить да прояснит.

Посмотрел его исходник (выглядит в целом ужасно, я б всё переписал) - не знаю какая у тебя версия, есть 2.8.0 и 2.8.1 последние.

Библиотека грузится тут: https://github.com/networkupstools/nut/blob/master/tools/nut-scanner/nutscan-init.c (поиск по слову libusb-) там get_libname("libusb-1.0.so") по сути получается

Сам get_libname тут: https://github.com/networkupstools/nut/blob/master/common/common.c

В 2.8.0 там был какой-то странный код который сначала искал в списке путей всё, что начинается на «libusb-1.0.so» а потом (например, нашёл libusb-1.0.so.12345) с помощью функции realpath пытался узнать, а нет ли в той же директории самого libusb-1.0.so. В версии которая в мастере по ссылке - эта функция распухла в несколько раз, в неё добавили в т.ч. поддержку LD_LIBRARY_PATH (а ещё - поиск файлов с добавками в конце убрали, но идиотскую схему «вручную перебираем весь список» и самодельную реализацию strcmp через strncmp оставили), но файл, который оно ищет должен, как и раньше, называться именно так: libusb-1.0.so безо всяких добавок, и это жёстко прописано в исходнике.

А ещё кажется если его запустить с -D -D (2 раза) то он будет писать отладочные надписи о том, где что ищет и что нашёл.

не знаю какая у тебя версия

2.8.0.

В 2.8.0 там был какой-то странный код который сначала искал в списке путей всё, что начинается на «libusb-1.0.so» а потом (например, нашёл libusb-1.0.so.12345) с помощью функции realpath пытался узнать, а нет ли в той же директории самого libusb-1.0.so. В версии которая в мастере по ссылке - эта функция распухла в несколько раз, в неё добавили в т.ч. поддержку LD_LIBRARY_PATH (а ещё - поиск файлов с добавками в конце убрали, но идиотскую схему «вручную перебираем весь список» и самодельную реализацию strcmp через strncmp оставили), но файл, который оно ищет должен, как и раньше, называться именно так: libusb-1.0.so безо всяких добавок, и это жёстко прописано в исходнике.

Спасибо за подробный разбор. Ну нет, так нет. Если ещё когда-нибудь понадобится, буду опять руками создавать симлинк с именем libusb-1.0.so.

если его запустить с -D -D (2 раза) то он будет писать отладочные надписи о том, где что ищет и что нашёл.

Да, пишет.

временно убрать этот текстовый файл, заменить на симлинк к библиотеке и посмотреть что будет

Если так, то работает нормально.

Ну нет, так нет. Если ещё когда-нибудь понадобится, буду опять руками создавать симлинк с именем libusb-1.0.so.

Оно хоть LD_LIBRARY_PATH и не поддерживает, но список директорий где ищет то большой. При запуске с -D -D оно с 1 раза находит текстовый файл или может перед ним есть ещё места где ничего нет и куда симлинк можно засунуть на постоянной основе?

При запуске с -D -D оно с 1 раза находит текстовый файл или может перед ним есть ещё места где ничего нет и куда симлинк можно засунуть на постоянной основе?

Оно начинает с текстового файла.

Как я уже сказал, UPS я исследую нечасто :) Поэтому можно и скопировать.

Если так, то работает нормально.

Чем всё закончилось - создали ли вы запись в багтрекере или внесли изменения в сам билд? Отправили ли изменения в основную ветку генты?

В моей генте

alexv@home ~> file /usr/lib64/libusb-1.0.so                                                                                                                                                                        (base) 
/usr/lib64/libusb-1.0.so: symbolic link to libusb-1.0.so.0.3.0

Помню год-два назад была какая толчея с раздельным /usr и симлинками. Может у тебя тогда что-то сломалось? Я тогда всё сделал, как в eselect news писали сделать.

Чем всё закончилось - создали ли вы запись в багтрекере или внесли изменения в сам билд? Отправили ли изменения в основную ветку генты?

В Генте баг висит уже много лет. Как и другой, из-за которого линкеру нужен этот странный скрипт. Исправлять проблемы линкера я не берусь — квалификации не хватит.

Но это же очевидно не линкера проблема, это ебилд неправильно устанавливает симлинки?

Этот файл нужен линкеру. И его же первым выбирает nut-scanner. Оба ведут себя не вполне правильно, но в нормально работающей системе это не проблема. Проблема — когда в одной системе таких костыльных кривулин несколько.

Какой «этот», зачем нужен линкеру? И что что nut-scanner его выбирает? Почему оба ведут себя неправильно, если при правильном расположении файлов на диске и правильных симлинках всё работает? Надо просто поправить .ebuild и тогда и линкер и nut-scanner будут оба брать правильный файл.

Надо просто поправить .ebuild

Почему бы тебе не заняться этим?

Какой «этот»,

/usr/lib64/libusb-1.0.so

зачем нужен линкеру?

Для компиляции программ, использующих dev-libs/libusb.

Надо просто поправить .ebuild

И отвалится компиляция чего-то ещё.

Только патчить sys-power/nut. Но для следующей версии этот патч придётся полностью переделывать.

И отвалится компиляция чего-то ещё.

Не отвалится, для компиляции /usr/lib64/libusb-1.0.so это подходящий путь и название.

патчить sys-power/nut

Но он же как раз и пытается грузить с правильного места, но у него не получается.

Ознакомься с багами по ссылкам, любезно предоставленным Пинкбайтом.

Да, возможно, что сама программа грузит библиотеку откуда-то неоттуда. Но там приложили патч. И верно, что там говорят о каком-то баге в каком-то вспомогательном скрипте, но это давно было и надо всё ресёрчить по-новой (потому что они не задокументировали всё достаточно хорошо). Я сочувствую твоей проблеме.