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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]