Re: [libvirt] [PATCH] build: force libnl1 if netcf also used libnl1
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(a)redhat.com +1-919-301-3266
Libvirt virtualization library http://libvirt.org
Attachments:
- signature.asc (application/pgp-signature — 617 bytes)