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 eblake@xxxxxxxxxx +1-919-301-3266
Libvirt virtualization library http://libvirt.org
Attachment:
signature.asc
Description: OpenPGP digital signature
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list