On 09/10/2012 11:50 AM, Eric Blake wrote:
On 09/07/2012 06:42 PM, Eric Blake wrote:
Recent spec file changes ensure that in distro situations, netcf and libvirt will link against the same libnl in order to avoid dumping core. But for every-day development, if you are F17 and have the libnl3-devel headers available, libvirt was blindly linking against libnl3 even though F17 netcf still links against libnl1, making testing a self-built binary on F17 impossible.
By making configure a little bit smarter, we can avoid this situation. I intentionally wrote the test so that we still favor libnl-3 if netcf is not installed or if we couldn't use ldd to determine which library netcf linked against.
* configure.ac (LIBNL): Don't probe libnl3 if netcf doesn't use it. ---
Does this patch look safe enough to use? It was sufficient to let me resume self-tests on my F17 box, where I had intentionally installed libnl3-devel. After thinking about it for a bit, I only have two concerns:
1) is it possible to force either libnl1 or libnl3 from the configure commandline, and fail if the requested version isn't available? I think it's nice to have it default to the libnl version used by the installed netcf, but may not always be what's wanted. Forcing libnl1 is definitely possible (by priming the cache for the *_cv_* variables set while doing the probe); I'm not yet sure if it is
On 09/08/2012 11:19 AM, Laine Stump wrote: possible to force libnl3. What I may do is a v2 patch, where if $LIBNL or the appropriate *_cv_* variables are set, we skip out on the ldd probe; leaving the ldd probe only for the case of a default build. After all, it is the default build where people don't know what variables to override in the first place where it makes the most sense; but if a user has already requested $LIBNL, then they know which library they are using. I'll look into it a bit more.
2) ncftool isn't installed unless the package "netcf" is installed, but running libvirt only requires netcf-libs, and building only requires netcf-devel + netcf-libs. How about checking the version of libnl that libnetcf.so is linked against instead? Of course this is a bit more complex, because you can't just look in $PATH, but if there's a simple way to locate that file, it's more likely to be on the system. (If not, checking ncftool is better than no check at all.) You're right there, as well. Maybe it is sufficient to just do:
for dir in /usr/lib /usr/lib64; do if test -f $dir/libnetcf.so; then ldd $dir/libnetcf.so fi done
when computing the ldd output. And remember, the ldd output is _only_ used to skip the libnl3 probe; if we fail to find libnetcf.so, we merely end up probing both libnl libraries, and may pick the wrong one; but that goes back to question 1, where as long as you are able to supply explicit configure arguments to override the defaults, then we are safe.
Okay. Regardless of the outcome, as long as those two issues are considered, then I'll be happy to ACK whatever you subsequently deem as most appropriate.