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.
--
Eric Blake [email protected] +1-919-301-3266
Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
-- libvir-list mailing list [email protected] https://www.redhat.com/mailman/listinfo/libvir-list
