On 05/19/2010 03:29 PM, Cole Robinson wrote:
I've hit a few small build issues that I don't know how to fix.
daemon/libvirtd.init isn't regenerated if ./configure is re-run. If I do:
./configure --prefix=/foo && make && ./configure --prefix=/bar && make
daemon/libvirtd.init will reference /foo and not /bar. The logrotate files are affected as well.
I think this one can be solved by adding a dependency on config.status; testing my theory now, and hopefully I will have a patch in the near future.
Second issue involves root squash homedir which I use regularly for development. If I ./configure && make -j4 && sudo make install, I get the following error:
Making install in python make[1]: Entering directory `/mnt/storage.bos/boston/crobinso/sandbox/upstream/libvirt/libvirt.git/python' Making install in . make[2]: Entering directory `/mnt/storage.bos/boston/crobinso/sandbox/upstream/libvirt/libvirt.git/python' make[3]: Entering directory `/mnt/storage.bos/boston/crobinso/sandbox/upstream/libvirt/libvirt.git/python' test -z "/usr/lib64/python2.6/site-packages" || /bin/mkdir -p "/usr/lib64/python2.6/site-packages" /bin/sh ../libtool --mode=install /usr/bin/install -c libvirtmod.la '/usr/lib64/python2.6/site-packages' libtool: install: warning: relinking `libvirtmod.la'
Unfortunately, I don't know libtool as well as I'd like. Here, you may be better off asking on the bug-libtool@gnu.org list. I do know that GNU Coding Conventions state that 'make install' should not do any compilation or linking if 'make all' is up-to-date, but I also know that libtool has a documented bug of not being able to always obey that rule on some platforms, because it must do a relink as part of installation to get path dependencies right. On the other hand, I seem to recall that on Linux, where .so can be compiled with rpath information up front, libtool can be smart enough to avoid the relink, but I don't know the magic to make that happen. -- Eric Blake eblake@redhat.com +1-801-349-2682 Libvirt virtualization library http://libvirt.org