[libvirt] [PATCH] build: force libnl1 if netcf also used libnl1

[Eric Blake]

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 at redhat.com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 617 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20120910/5c8e6a3a/attachment-0001.sig>