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

[Laine Stump]

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.