Iperf: make installにldconfigが必要ですか？

CentOS 6のiperf3マスターブランチの先端からのコードでこれをテストしました。ldconfigは「makeinstall」の一部として呼び出されました（これはlibtool --mode = installによって行われることの一部のようです）。 iperf3は、インストール後すぐに共有ライブラリを見つけることができました。手動のldconfigは必要ありません。 これはLinuxディストリビューションに固有のものなのだろうか？

別のUbuntuシステムでのこの問題に関するもう1つのレポート、同じ症状。 このシステムは、Ubuntu 12.04.3 LTS（GNU / Linux 3.8.0-31-generic i686）でした。

新しいlibtool / autoconf / automakeに行くことがこの問題に役立つかどうか疑問に思いますか？

OK、これをUbuntu VMで再現することができました（12.04 LTS、もちろん14.04 LTSがリリースされたのと同じ日に作成しました）。 まだUbuntuで少し動き回っているので、まだ解決策についてはそれほど進んでいません。

ldconfigの実行は、Debian Wheezy（7.5）64ビットでも必要でした。 乾杯、

更新：誰か（私はそれが誰であったかを忘れています）が、Ubuntu Trusty（14.04 LTS）でこの問題を見たとGoogleCodeの課題追跡システムに投稿しました。 これを（ファッションの後で）CentOS6で再現することもできました。

問題は、共有ライブラリをインストールした後、自動生成されたMakefileグープが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-または-di-td3970.html

1つの提案は、次のようなものをsrc/Makefile.amに追加することです。

install-exec-hook:
        ldconfig

これで問題が修正されたようです... make installテストした直後に、CentOS6とUbuntu12.04LTSでiperf3を呼び出しました。

これにより、root以外のユーザーとしてインストールしようとする人々にいくつかの問題が発生しました（ユースケースは、プライベートディレクトリ階層にインストールするか、root以外のユーザーとしてRPMを構築することです）。 基本的に、呼び出されたldconfigは、十分なファイルパーミッションが不足しているため、root以外として実行することは望ましくありません。

おそらく、ldconfigの呼び出しを次のように変更する必要があります。

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

この問題を再度開いて、もう一度試してください。

これは、ldconfigを使用しないMacOSでは機能せず、実際、そのプラットフォームでエラーが発生します。

このバグを3.1でターゲットにします。 既知の問題のセクションにアイテムがあるだけの場合でも、何らかの方法でこれを解決する必要があります。

これは実際には一般的なソフトウェアインストールの問題です。 複数のプラットフォーム間でこれを行うのは難しいため、ここでは解決しません。 修正なしで終了します。

Ubuntuディストリビューションで/usr/lib32 /usr/local/libではなくmake install最後でldconfig /usr/local/lib （rootが必要）を実行するだけです。

この簡単な回避策を適用して、Ubuntuユーザーがiperf3をインストールできるようにしてください。

参照： http ：

「makeinstall」で問題が解決した後、ldconfigを実行していただきありがとうございます。

Debian 7.8 64ビット（wheezy）を実行しています。 タイトルに規定されている問題が発生した場合は、「sudo ldconfig」postmake installを実行し、正常に動作するようになりました。 このスレッドで助けてくれてありがとう。

これをubuntuの最新バージョン（3.1.3）で使用する必要がありました。 これがすべてのubuntuバージョンに必要な要件である場合は、ユーザーが開始するためにgoogle / githubを検索する必要がないように、もう少し明確にする価値があることをお勧めします。

ここではUbuntu16.04（Xenial Xerus）と同じです。
私のような誰かが再び迷子にならない限り、ubuntuはこれについて警告サインを作る方が良いです....

Mac OSXでのiperf3エラーの修正はありますか？ 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）。
• クロスコンパイル。

2014年6月10日に提案したようなことを考えていますが、エラー状態は無視しています。 誰かがクロスコンパイルのケースについてコメントできれば素晴らしいと思います...他のプラットフォーム用にクロスコンパイルしている場合は、ファイルをどこかにステージングするためにmake install全体を実行しますか、それともmake compileだけを実行しますか

私はこの問題に遭遇しました、そしてあなたが私が修正を理解するのを手伝ってくれることを望んでいました。

armv5 QNAPNASでiperf3を実行しようとしています。

なんとかインストールできました。 しかし、それを実行すると、この問題が発生します： iperf3: error while loading shared libraries: libiperf.so.0: cannot open shared object file: No such file or directory

ldconfig （w /またはw / o 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に追加して、運が悪ければ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は、makeinstallの後にldconfigを実行する必要がないというリストに含まれます。

余談ですが、どのシステムを実行するのにldconfigを必要としないのか、そしてそれをどのように管理するのかについて興味があります。

閉鎖。 これはiperf3の問題だけではなく、他の誰もそれに対する良い解決策を持っていないようです。 （automakeとlibtoolのいくつかの組み合わせでこの問題に対処する必要があると思います。）

はい、libtoolの問題のようです。 前回これを追いかけたとき、GNUバグトラッカーで次のことを見つけました。

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

1997年に、実行方法であるlibtoolバージョン0.6bに対して7f9b4e50をコミットします。
ldconfigは、「-n」なしでの実行から「-n」付きでの実行に変更されました。

そこでの議論に基づくと、これが元に戻る可能性は低いと思われます。これは、非常に多くの時間が経過し、変更の理由と、元に戻すことによるリスクの可能性が十分に理解されていないためです。 誰かが将来この問題に遭遇し、とにかく修正を試みたい場合、それはおそらくあなたがそれを正しく行うのと同じくらい近いでしょう。