On 09/10/2012 11:50 AM, Eric Blake wrote: > On 09/08/2012 11:19 AM, Laine Stump 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 > 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. -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list