Fix runtime linking when installed outside default prefix (#153) #934
Conversation
When libiperf was installed in a directory not searched by default (e.g. /usr/local/lib on some systems), iperf3 would fail to find it at runtime. Pass -rpath when linking iperf3 to remedy this. The problem was originally discovered on Ubuntu Linux.
|
I ran into this while looking for the best practice solution for a similar situation in one of my projects. This is the solution I ended up with. It's a small change, so I thought maybe it'd work for you too. |
|
Thanks for the PR...that's very helpful. Wondering if anyone who packages iperf3 for their OS/distro has any feedback/comments on this change? |
|
I don't package iperf3 myself, but I have experience with packaging for openSUSE. With my packager hat on, I'd probably patch out the -rpath to make linking consistent with the rest of the platform and because the package installs to a standard location. A possible compromise would be to make it optional (on by default) and add a --without-rpath flag to configure. Historically, using -rpath to link with libraries in common paths has been frowned upon, because the DT_RPATH entry makes binaries impossible to relocate -- i.e. it would always look for the library at the full path first and if found, would ignore LD_LIBRARY_PATH and other attempts to override it. Newer ld (since ~2017) adds DT_RUNPATH which has a lower priority than LD_LIBRARY_PATH, so it's less of a problem than it used to be. The Debian wiki has a useful summary. It's probably representative of how packagers think about the situation. |
|
After a really long time, we decided to give up on #153 and not try to solve it, so I'm going to respectfully decline this pull request. Thank you for the submission! |
When libiperf was installed in a directory not searched by default (e.g. /usr/local/lib on some systems), iperf3 would fail to find it at runtime. Pass -rpath when linking iperf3 to remedy this. The problem was originally discovered on Ubuntu Linux.