Iperf: 进行安装时需要ldconfig吗？

我刚刚在CentOS 6的iperf3 master分支的顶端的代码中对此进行了测试。ldconfig作为“ make install”的一部分被我调用（这似乎是libtool --mode = install的一部分），而且iperf3可以在安装后立即找到其共享库，无需手动ldconfig。 我想知道这是否特定于Linux发行版吗？

另一个在另一个Ubuntu系统上报告此问题的症状相同。 该系统是：Ubuntu 12.04.3 LTS（GNU / Linux 3.8.0-31-通用i686）。

我想知道是否可以使用较新的libtool / autoconf / automake来解决此问题？

好的，我能够在Ubuntu VM（12.04 LTS，当然，我在14.04 LTS推出的同一天就建立了它）上重现了这一点。 仍然在Ubuntu上徘徊了一点，所以还没有真正的解决方案。

在Debian Wheezy（7.5）64位上也需要运行ldconfig。 干杯，

更新：有人（我忘记了它是谁）发布到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

这似乎已经解决了问题...在CentOS 6和Ubuntu 12.04 LTS上立即进行了make install测试，然后进行了iperf3调用。

这给尝试以非root用户身份安装的人们造成了一些问题（用例正在安装到私有目录层次结构或以非root用户身份构建RPM）。 基本上，调用ldconfig时，它不希望以非root用户身份运行，因为它缺少足够的文件权限。

也许应该将ldconfig调用更改为执行以下操作：

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

重新打开此问题以再次尝试。

这不适用于不使用ldconfig的MacOS，实际上会在该平台上导致错误。

针对此错误针对3.1。 我们需要以某种方式解决此问题，即使只是已知问题部分中的内容也是如此。

这确实是一个通用的软件安装问题。 考虑到跨多个平台执行此操作的困难，我们将不在这里解决它。 没有修复的关闭。

如果你想坚持到/usr/local/lib ，而不是/usr/lib32 Ubuntu的发行版，然后只需运行ldconfig /usr/local/lib （需要根）在结束make install 。

请应用此快速解决方法，以允许Ubuntu用户安装iperf3。

请参阅： http ：

感谢在“ make install”为我解决问题之后运行ldconfig。

运行Debian 7.8 64Bit（heyy）。 如果标题中指定了问题，请运行“ sudo ldconfig”进行make install，现在可以正常运行了。 感谢您对此线程的帮助。

必须在ubuntu的最新版本（3.1.3）上使用它。 如果这是所有ubuntu版本的必要要求，我建议值得一提，使其更加明显，以便用户无需搜索google / github即可开始

与Ubuntu 16.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，那是一个单独的项目，您可能应该与他们接洽（我不确定这里是否有bug）。

@ jmack51 ：啊，无视，我知道您已经在哪里打开了thiezn / iperf3-python问题。

感谢布鲁斯（Bruce），对垃圾邮件表示抱歉，因为https://github.com/thiezn/iperf3-python/issues/23中的记录已结束

尽管我对如何解决这个问题并不了解，但我将重新讨论该问题。 有各种用例：

• 需要运行ldconfig的系统。
• 不需要ldconfig的系统。
• 需要带有一些参数（例如，路径名）的ldconfig的系统。
• 没有ldconfig的系统（例如macOS）。
• 交叉编译。

我在想类似我在2014年6月10日提出的建议，但忽略了错误情况。 如果有人可以在交叉编译的情况下发表评论，那将是很棒的……如果您要在其他平台上进行交叉编译，您会执行完整的make install来将文件暂存到某个地方还是只是make compile ？

我遇到了这个问题，希望您能帮助我解决问题。

我试图在armv5 QNAP NAS上运行iperf3。

我设法安装了它。 但是运行它，我会遇到以下问题： 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的构建过程可以在控制台上显示消息，提示应该运行的命令。 一旦有了，就切入实际。

是否列出了需要运行ldconfig的哪些（* nix）系统，而哪些不需要？ 在完成安装后，macOS和Windows属于不需要运行ldconfig的列表。

顺便说一句，我很好奇哪个系统不需要ldconfig来运行以及如何管理。

闭幕。 这不仅是一个iperf3问题，而且似乎没有其他人对此有一个好的解决方案。 （我认为应该使用automake和libtool的某种组合来处理此问题。）

是的，这似乎是一个libtool问题。 上一次我追求这一点时，在GNU Bug跟踪器中发现了以下内容：

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

在1997年，为libtool 0.6b版（运行方式）提交7f9b4e50
ldconfig从不带“ -n”的运行更改为带“ -n”的运行。

根据讨论，似乎不太可能恢复原状，因为已经花费了很多时间，而且对于更改的理由以及将其改回的潜在风险似乎知之甚少。 如果将来有人遇到此问题，并且仍想尝试修复，则可能与正确地完成修复工作很接近。