Iperf: ldconfig needed in make install?

I just tested this on code from the tip of the iperf3 master branch on CentOS 6. ldconfig was invoked for me as a part of "make install" (this appears to be a part of what's done by libtool --mode=install), and the iperf3 was able to find its shared library immediately after installation, no manual ldconfig needed. I wonder if this is something that's specific to a Linux distribution?

One other report of this problem on another Ubuntu system, same symptoms. This system was: Ubuntu 12.04.3 LTS (GNU/Linux 3.8.0-31-generic i686).

I wonder if going to a newer libtool / autoconf / automake would help this problem?

OK I was able to reproduce this on an Ubuntu VM (12.04 LTS, which of course I built up the very same day that 14.04 LTS came out). Still flailing around a little bit on Ubuntu, so haven't really gotten that far with a solution yet.

Running ldconfig was also needed on Debian Wheezy (7.5) 64bit. Cheers,

Update: Someone (I forget who it was) posted to the Google Code issue tracker that they saw this problem on Ubuntu Trusty (14.04 LTS). I was also able to reproduce this (after a fashion) on CentOS 6.

The problem seems to be that after installing shared libraries, the autogenerated Makefile goop runs ldconfig -n /usr/local/lib. This rebuilds some symlinks for the newly installed libraries. However, according to ldconfig(8), -n implies -N, which causes the shared library cache to not be rebuilt, which is exactly the issue we're seeing. Running ldconfig with no arguments rebuilds the cache.

This appears to be a long-standing issue with some combination of automake and libtool...lots of interesting (even though old) details here:

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

One suggestion is to add something like this to src/Makefile.am:

install-exec-hook:
        ldconfig

This seems to have fixed the problem...tested with make install immediately followed by iperf3 invocation on CentOS 6 and Ubuntu 12.04 LTS.

This has caused a few problems with people trying to install as a non-root user (use cases are installing to a private directory hierarchy or building an RPM as a non-root user). Basically ldconfig as invoked doesn't want to be run as non-root because it would lack sufficient file permissions.

Perhaps the ldconfig invocation should be changed to do something like:

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

Reopening this issue to give this another try.

This doesn't work on MacOS, which doesn't use ldconfig, and in fact causes errors on that platform.

Targeting this bug for 3.1. One way or another we need to have some kind of resolution for this, even if it's just having the item in the known issues section.

This really is a generic software installation problem. We're not going to solve it here, given the difficulties in doing this across multiple platforms. Closing without a fix.

If you want to stick to /usr/local/lib instead of /usr/lib32 on Ubuntu distro, then just run ldconfig /usr/local/lib (requires root) at the end of make install.

Please apply this quick workaround to allow Ubuntu users to install iperf3.

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

Thanks running ldconfig after "make install" solved the issue for me.

Running Debian 7.8 64Bit (wheezy). Had the issue as prescribed in the title, ran 'sudo ldconfig' post make install, working fine now. Thanks for the help in this thread.

Had to use this on latest version (3.1.3) with ubuntu. If this is to be a necessary requirement for all ubuntu versions I suggest its worthwhile making it a bit more obvious so that the user wont need to search google / github to get going

Same here with Ubuntu 16.04 (Xenial Xerus).
ubuntu better make warning signs about this unless someone like me get lost again....

Does anyone have a fix for the iperf3 error on Mac OSX? With iperf3 3.2, using the Python wrapper, I'm seeing libiperf.so.0 is not found.

@jmack51: On mac OS, there won't be a *.so.0 shared library...mac OS uses a *.dynlib extension for its shared libraries. If "the Python wrapper" refers to iperf3-python, that's a separate project and you probably ought to take this up with them (I'm not sure if there's a bug here or not).

@jmack51: Ah, disregard, I see where you already opened an issue with thiezn/iperf3-python.

Thanks Bruce, sorry for the spam, for the record that's over in https://github.com/thiezn/iperf3-python/issues/23

I'm going to re-open this issue, even though I don't have a great idea about how to fix it. There are various use cases:

• Systems that need ldconfig to be run.
• Systems that don't need ldconfig.,
• Systems that need ldconfig with some parameters (e.g. a pathname).
• Systems with no ldconfig (e.g. macOS).
• Cross-compiling.

I'm thinking something like what I proposed on June 10, 2014, but ignoring error conditions. It'd be great if someone could comment on the cross-compiling case...if you're cross-compiling for some other platform do you do the full make install to stage the files somewhere or just make compile?

I've run into this issue, and was hoping you could help me figure out a fix.

I'm trying to run iperf3 on my armv5 QNAP NAS.

I managed to install it. But running it, I get this issue: iperf3: error while loading shared libraries: libiperf.so.0: cannot open shared object file: No such file or directory

ldconfig (w/ or w/o sudo) didn't fix it unfortunately.

[/] # 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 from / gives
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*

I've tried adding /mnt/ext/usr/local/lib to /etc/ld.so.conf and _then_ running ldconfig without luck.

This is what it looked like before (and I have since removed it again):

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

What can I do/try?

@BeyondEvil have you tried to use LD_LIBRARY_PATH environmental variable?

@ralcini No I haven't, (I think). I'll give it a try. 👍

For the cross compiling query in https://github.com/esnet/iperf/issues/153#issuecomment-365012358, I've used make install extensively. I'd guess that most build systems do it as well - particularly if a project is autotool-ized.

I'd suggest as a first stab at this, the iperf build process could put out messages onto the console suggesting the command that ought to be run. Once we have that, cut over to actually doing it.

Is there a listing of which (*nix)systems need ldconfig to be run, and which don't ? macOS and Windows fall into the list of not requiring ldconfig to be run after make install.

As an aside, I'm curious as to which systems don't need ldconfig to run and how thats managed.

Closing. This isn't solely an iperf3 problem, and it seems like nobody else has a good solution for it either. (I would posit that some combination of automake and libtool should be dealing with this issue.)

Yes, it seems like a libtool issue. The last time I went chasing this, I found the following in the GNU bug tracker:

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

In 1997, commit 7f9b4e50 for libtool version 0.6b, the way of running
ldconfig was changed from running without "-n" to running with "-n".

Based on the discussion there it seems unlikely that this will be reverted, since so much time has passed and the rationale for the change and the risk potential from changing it back seem to be poorly understood. If someone comes across this issue in the future and wants to try for a fix anyway, that's probably as close as you'll get to doing it correctly.