On 03/19/2014 03:15 PM, Howard Tsai wrote:

Hello,

I am wondering why AC_PATH_PROG is used to detect the location of run-time external programs (such as dnsmasq, ovs-vsctl, etc.), and hardcoded the locations in binary. It seems wrong to me.

It is only hard-coding the default location of the tools. You are free to override that, by using ./configure OVSVSCTL=/path/to/the/destinat*ion/ovs-vsctl to force the binary to be built with the hard-coded location you plan on using in your installation, or use ./configure OVSVSCTL=ovs-vsctl to force libvirtd to do a PATH lookup every time.

At compile-time, configure script should only determine whether the resulting binary should support the use of these external programs. The actual location of these programs should be determined at run-time, either from libvirtd.conf or by $PATH.

Deferring the decision to libvirtd.conf might be feasible, albeit more complex. Propose a patch, and we'll look at it. But for now, the default is good enough, and over-ridable at configure time, so it's not something that I'm personally bothered by enough to write a patch myself. By the way, we DO prefer hard-coded locations over PATH lookups, because PATH lookups can result in odd behavior when two people run qemu:///session with different PATH, and where the lookup may pick up a different binary for the two users. Configuring a hard-coded location requires a bit more planning, but is more secure - and since MOST users go with pre-built distributions, the hard-coded binaries can be guaranteed* to be present (for example, the rpm files used by Fedora guarantee that for any tool where we hard-code the location into the libvirt binary as living in /usr/bin will also be a prereq of the package, so that if you install libvirt, you also install the prereq packages that libvirt will try to use). [*Of course, if you ever hit a case where this guarantee is not met, file a bug against the distro to inform them of the missing dependency]

I haven't looked into how to fix it.

The problem I ran into earlier is this: on my dev box, I have Open vSwitch utility ovs-vsctl installed locally in /usr/local/bin. Therefore, at build-time, libvirt detected the location of ovs-vsctl and hardcoded '/usr/local/bin/ovs-vsctl' in libvirtd. When I package libvirt and install it on my test box, it couldn't find ovs-vsctl, as ovs-vsctl is installed at /usr/bin/ovs-vsctl in the test box, so it failed.

Again, that's a matter of setting up OVSVSCTL on your dev box to match the location where the binary will be present on your test box. -- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org