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(a)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(a)redhat.com +1-801-349-2682
Libvirt virtualization library
http://libvirt.org