Iperf: ldconfig нужен в make install?

Я только что протестировал это на коде из конца ветки master iperf3 в CentOS 6. ldconfig был вызван для меня как часть "make install" (похоже, это часть того, что делается libtool --mode = install), и iperf3 смог найти свою общую библиотеку сразу после установки, никакой ручной ldconfig не требуется. Интересно, характерно ли это для дистрибутива Linux?

Еще один отчет об этой проблеме в другой системе Ubuntu, симптомы те же. Эта система была: Ubuntu 12.04.3 LTS (GNU / Linux 3.8.0-31-generic i686).

Интересно, поможет ли переход на более новую версию libtool / autoconf / automake с этой проблемой?

Хорошо, я смог воспроизвести это на виртуальной машине Ubuntu (12.04 LTS, которую, конечно же, я создал в тот же день, когда вышел 14.04 LTS). Все еще немного копаюсь в Ubuntu, так что еще не дошел до этого с решением.

Запуск ldconfig также требовался в Debian Wheezy (7.5) 64bit. Привет,

Обновление: кто-то (я забыл, кто это был) написал в системе отслеживания проблем Google Code, что они видели эту проблему в Ubuntu Trusty (14.04 LTS). Я также смог воспроизвести это (в некоторой степени) на CentOS 6.

Проблема, похоже, в том, что после установки разделяемых библиотек автоматически сгенерированный файл Makefile goop запускает ldconfig -n /usr/local/lib . Это восстанавливает некоторые символические ссылки для недавно установленных библиотек. Однако, согласно ldconfig (8), -n подразумевает -N , из-за чего кеш разделяемой библиотеки не перестраивается, и это именно та проблема, которую мы наблюдаем. Запуск ldconfig без аргументов перестраивает кеш.

Похоже, что это давняя проблема с некоторой комбинацией automake и libtool ... здесь много интересных (хотя и старых) деталей:

http://gnu-automake.7480.n7.nabble.com/quot-error- while-loading-shared-libraries-foo-so-0-cannot-open-shared-object-file-No-such-file- or-di-td3970.html

Одно из предложений - добавить что-то вроде этого в src/Makefile.am :

install-exec-hook:
        ldconfig

Похоже, это устранило проблему ... протестировано с make install сразу за которым следует вызов iperf3 в CentOS 6 и Ubuntu 12.04 LTS.

Это вызвало несколько проблем с людьми, пытающимися установить систему от имени пользователя без полномочий root (варианты использования: установка в иерархию частных каталогов или создание RPM от имени пользователя без полномочий root). В основном ldconfig при вызове не хочет запускаться от имени пользователя без полномочий root, потому что ему не хватит прав доступа к файлам.

Возможно, вызов ldconfig следует изменить, чтобы он делал что-то вроде:

install-exec-hook:
        if [ "x`id -u $USER`" = "x0" ]; then ldconfig; fi

Повторное открытие этой проблемы, чтобы попробовать еще раз.

Это не работает в MacOS, где не используется ldconfig, и фактически вызывает ошибки на этой платформе.

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

Это действительно общая проблема установки программного обеспечения. Мы не собираемся решать эту проблему здесь, учитывая трудности, связанные с выполнением этой задачи на нескольких платформах. Закрытие без исправления.

Если вы хотите придерживаться /usr/local/lib вместо /usr/lib32 в дистрибутиве Ubuntu, просто запустите ldconfig /usr/local/lib (требуется root) в конце make install .

Пожалуйста, примените этот быстрый обходной путь, чтобы пользователи Ubuntu могли установить iperf3.

См .: http://stackoverflow.com/questions/4743233/is-usr-local-lib-searched-for-shared-libraries

Спасибо, что запустил ldconfig после того, как "make install" решил проблему.

Запуск Debian 7.8 64Bit (хрипит). Если проблема была указана в заголовке, запустил команду sudo ldconfig после make install, теперь все работает нормально. Спасибо за помощь в этой теме.

Пришлось использовать это в последней версии (3.1.3) с ubuntu. Если это является необходимым требованием для всех версий ubuntu, я предлагаю сделать его более очевидным, чтобы пользователю не нужно было искать в google / github, чтобы начать работу.

То же самое и с Ubuntu 16.04 (Xenial Xerus).
Ubuntu лучше предупредить об этом, если кто-то вроде меня снова не заблудится ...

Есть ли у кого-нибудь исправление ошибки iperf3 на Mac OSX? С iperf3 3.2, используя оболочку Python, я вижу, что libiperf.so.0 не найден.

@ jmack51 : В Mac OS не будет разделяемой библиотеки *.so.0 ... Mac OS использует расширение *.dynlib для своих разделяемых библиотек. Если «оболочка Python» относится к iperf3-python, это отдельный проект, и вам, вероятно, следует заняться этим вместе с ними (я не уверен, есть ли здесь ошибка или нет).

@ jmack51 : Ах, не обращайте внимания, я вижу, где вы уже открыли проблему с thiezn / iperf3-python.

Спасибо, Брюс, извините за спам, за запись, которая закончилась на https://github.com/thiezn/iperf3-python/issues/23

Я собираюсь повторно открыть эту проблему, хотя и не знаю, как ее исправить. Существуют различные варианты использования:

• Системы, которым требуется запуск ldconfig.
• Системы, которым не нужен ldconfig.,
• Системы, которым требуется ldconfig с некоторыми параметрами (например, путем).
• Системы без ldconfig (например, macOS).
• Кросс-компиляция.

Я думаю о чем-то вроде того, что предлагал 10 июня 2014 г., но игнорирую условия ошибки. Было бы здорово, если бы кто-нибудь мог прокомментировать случай кросс-компиляции ... если вы выполняете кросс-компиляцию для какой-то другой платформы, делаете ли вы все make install для размещения файлов где-то или просто make compile ?

Я столкнулся с этой проблемой и надеялся, что вы поможете мне найти решение.

Я пытаюсь запустить iperf3 на своем сетевом хранилище QNAP armv5.

Удалось установить. Но запустив его, я получаю эту проблему: iperf3: error while loading shared libraries: libiperf.so.0: cannot open shared object file: No such file or directory

ldconfig (без sudo), к сожалению, не исправил.

[/] # find . -name libiperf.so.*
./mnt/ext/usr/local/lib/libiperf.so.0
./mnt/ext/usr/local/lib/libiperf.so.0.0.0
./share/HDA_DATA/homes/admin/downloads/iperf-3.5/src/.libs/libiperf.so.0.0.0
./share/HDA_DATA/homes/admin/downloads/iperf-3.5/src/.libs/libiperf.so.0

ls -la из / дает
lrwxrwxrwx 1 admin administ 12 Mar 30 10:18 usr -> /mnt/ext/usr/

[/usr/local/lib] # ls -la libiperf.s*
lrwxrwxrwx    1 admin    administ        17 Mar 30 21:32 libiperf.so -> libiperf.so.0.0.0*
lrwxrwxrwx    1 admin    administ        17 Mar 30 21:32 libiperf.so.0 -> libiperf.so.0.0.0*
-rwxr-xr-x    1 admin    administ    380032 Mar 30 21:32 libiperf.so.0.0.0*

Я пробовал добавить /mnt/ext/usr/local/lib к /etc/ld.so.conf и _then_ запустил ldconfig безуспешно.

Вот как это выглядело раньше (и с тех пор я снова удалил его):

[/mnt/ext/usr/local/lib] # cat /etc/ld.so.conf 
/lib
/usr/lib
/usr/local/lib

Что я могу сделать / попробовать?

@BeyondEvil пробовали ли вы использовать переменную окружения LD_LIBRARY_PATH?

@ralcini Нет, не

Для запроса кросс-компиляции в https://github.com/esnet/iperf/issues/153#issuecomment -365012358 я широко использовал make install . Я предполагаю, что большинство систем сборки также делают это, особенно если проект автоматизирован.

Я бы предложил в качестве первого удара по этому поводу, процесс сборки iperf мог бы выводить сообщения на консоль, предлагая команду, которую следует запустить. Как только у нас есть это, переходите к тому, чтобы делать это.

Есть ли список того, какие (* nix) системы требуют запуска ldconfig, а какие нет? macOS и Windows попадают в список, которым не требуется запуск ldconfig после make install.

Кстати, мне любопытно, какие системы не нуждаются в ldconfig для запуска и как это можно сделать.

Закрытие. Это не только проблема iperf3, и, похоже, ни у кого другого нет подходящего решения. (Я бы сказал, что с этой проблемой должна справляться какая-то комбинация automake и libtool.)

Да, похоже, проблема с libtool. В последний раз, когда я гонялся за этим, я обнаружил в системе отслеживания ошибок GNU следующее:

https://debbugs.gnu.org/cgi/bugreport.cgi?bug=30402

В 1997 году выполните фиксацию 7f9b4e50 для libtool версии 0.6b, способ запуска
ldconfig был изменен с работы без "-n" на работу с "-n".

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