On Mon, Feb 04, 2013 at 11:27:30AM +0100, Jiri Denemark wrote:
On Mon, Feb 04, 2013 at 09:41:58 +0800, Hu Tao wrote:
> On Fri, Feb 01, 2013 at 01:45:19PM +0100, Jiri Denemark wrote:
> > libvirt.c calls curl_global_init() if WITH_CURL is defined and thus it
> > should be linked with libcurl. This fixes link failure in case neither
> > xenapi nor esx driver is enabled (they are the only users of libcurl).
>
> In the case we link with libcurl just because user wants it. How about
> not exposing --with-curl but define WITH_CURL when needs to(xenapi or
> esx driver is enabled, or both)?
Yes, that would be the ideal solution. But this fix is correct even in
that case, no matter why WITH_CURL is defined if it is defined,
libvirt.c calls to libcurl and thus needs to link with it. Anyway, the
goal of the recent rewrite of our configure.ac by Daniel was to check
for all libraries we might need and then check what drivers we may
enable based on the libraries we have. I think removing libraries than
no driver wants might be in the long term goals but I'm not quite sure
about that.
The intent is that everything defaults to "check" - so we always
want to check each library, and if the libraries are present then
enable the hypervisor driver. The edge cases is that if you have
explicitly set one hypervisor driver to 'no', then we still are
checking libraries, since we want to avoid putting info about
hypervisors into the library checks.
So
--without-esx
would still leave curl enabled, but
--without-curl
would disable curl and esx. IMHO this is an acceptable tradeoff,
since this is an edge case, and there's still a way to deal with
it if desired.
Daniel
--
|:
http://berrange.com -o-
http://www.flickr.com/photos/dberrange/ :|
|:
http://libvirt.org -o-
http://virt-manager.org :|
|:
http://autobuild.org -o-
http://search.cpan.org/~danberr/ :|
|:
http://entangle-photo.org -o-
http://live.gnome.org/gtk-vnc :|