I followed the large thread posted in January re: building libvirt on OS X, but I seem to have run into a snag near the end of the compile: gcc -DHAVE_CONFIG_H -I. -I. -I.. -I../gnulib/lib -I../gnulib/lib -I../include -I../include -I../qemud -I/usr/include/libxml2 -DBINDIR=\"/usr/local/libexec\" -DSBINDIR=\"/usr/local/sbin\" -DSYSCONF_DIR=\"/usr/local/etc\" -DLOCALEBASEDIR=\"/usr/local/share/locale\" -DLOCAL_STATE_DIR=\"/usr/local/var\" -DGETTEXT_PACKAGE=\"libvirt\" -Wall -Wformat -Wformat-security -Wmissing-prototypes -Wnested-externs -Wpointer-arith -Wextra -Wshadow -Wcast-align -Wwrite-strings -Waggregate-return -Wstrict-prototypes -Winline -Wredundant-decls -Wno-sign-compare -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fasynchronous-unwind-tables -DWITH_TEST -DWITH_REMOTE -I /opt/local/include -L/opt/local/lib -DIN_LIBVIRT -I /opt/local/include -L/opt/local/lib -MT libvirt_la-storage_backend_fs.lo -MD -MP -MF .deps/libvirt_la-storage_backend_fs.Tpo -c storage_backend_fs.c -fno-common -DPIC -o .libs/libvirt_la-storage_backend_fs.o storage_backend_fs.c:34:20: error: endian.h: No such file or directory storage_backend_fs.c:35:22: error: byteswap.h: No such file or directory storage_backend_fs.c:36:20: error: mntent.h: No such file or directory storage_backend_fs.c:110: error: '__BIG_ENDIAN' undeclared here (not in a function) storage_backend_fs.c:143: error: '__LITTLE_ENDIAN' undeclared here (not in a function) storage_backend_fs.c: In function 'virStorageBackendProbeFile': storage_backend_fs.c:377: warning: comparison between pointer and integer storage_backend_fs.c:394: warning: comparison between pointer and integer storage_backend_fs.c: In function 'virStorageBackendFileSystemIsMounted': storage_backend_fs.c:458: error: '_PATH_MOUNTED' undeclared (first use in this function) storage_backend_fs.c:458: error: (Each undeclared identifier is reported only once storage_backend_fs.c:458: error: for each function it appears in.) storage_backend_fs.c:458: warning: passing argument 1 of 'fopen' from incompatible pointer type storage_backend_fs.c:461: warning: format '%s' expects type 'char *', but argument 4 has type 'struct <anonymous> *' storage_backend_fs.c:465: warning: implicit declaration of function 'getmntent' storage_backend_fs.c:465: warning: nested extern declaration of 'getmntent' storage_backend_fs.c:465: warning: assignment makes pointer from integer without a cast storage_backend_fs.c:466: error: dereferencing pointer to incomplete type storage_backend_fs.c:466: error: request for member 'mnt_dir' in something not a structure or union storage_backend_fs.c:466: warning: passing argument 1 of 'strcmp' from incompatible pointer type make[2]: *** [libvirt_la-storage_backend_fs.lo] Error 1 make[1]: *** [all-recursive] Error 1 make: *** [all] Error 2 endian.h does exist on OS X, but under a bits directory, but byteswap.h and mntent.h don't exist at all on the default X-Code install. Any ideas? - Pat
On Mon, Mar 03, 2008 at 04:02:49PM -0500, Pat Wendorf wrote:
endian.h does exist on OS X, but under a bits directory, but byteswap.h and mntent.h don't exist at all on the default X-Code install. Any ideas?
Yes ... Basic problem is that we develop extensions to libvirt and only ever test them on a single rather narrow platform (Fedora). We don't even compile, let alone test them even on Debian, nevermind FreeBSD, Solaris, Windows, Mac OS X ... For example, I got libvirt working on Windows and Mac OS X a while back, but it appears that this has now regressed again. The question is what do we want to do about this? Here are some ideas ... (1) Do nothing. [We are here now] (2) Get outside groups to support the other platforms and accept patches from them. Perhaps support those groups with space on the website (some website space already exists but it's out of date). (3) Set up some automated builders to build daily versions of libvirt on other platforms. "Name and shame" by posting the results to this list so hopefully people are motivated to make fixes. (4) Tier 1 support for the other platforms. Only accept patches which don't break them. (This one is a bit tricky because developers won't have / won't want to have access to some of the platforms in question). Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones virt-top is 'top' for virtual machines. Tiny program with many powerful monitoring features, net stats, disk stats, logging, etc. http://et.redhat.com/~rjones/virt-top
On Mon, Mar 03, 2008 at 09:43:50PM +0000, Richard W.M. Jones wrote:
(3) Set up some automated builders to build daily versions of libvirt on other platforms. "Name and shame" by posting the results to this list so hopefully people are motivated to make fixes.
We're already doing this internally for Xen. In theory, it shouldn't be too much harder to do the same with libvirt. Ryan? regards john
John Levon wrote:
On Mon, Mar 03, 2008 at 09:43:50PM +0000, Richard W.M. Jones wrote:
(3) Set up some automated builders to build daily versions of libvirt on other platforms. "Name and shame" by posting the results to this list so hopefully people are motivated to make fixes.
We're already doing this internally for Xen. In theory, it shouldn't be too much harder to do the same with libvirt. Ryan?
The biggest problem would be dealing with incoming patches that conflict with our internal patches. In particular, anything changing a Makefile would probably cause conflicts that I'd have to manually fix. But, I suppose that would be easier than the effort I'm putting in now, trying to merge the storage patches... -Ryan
regards john
-- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
On Mon, Mar 03, 2008 at 03:27:29PM -0800, Ryan Scott wrote:
John Levon wrote:
On Mon, Mar 03, 2008 at 09:43:50PM +0000, Richard W.M. Jones wrote:
(3) Set up some automated builders to build daily versions of libvirt on other platforms. "Name and shame" by posting the results to this list so hopefully people are motivated to make fixes.
We're already doing this internally for Xen. In theory, it shouldn't be too much harder to do the same with libvirt. Ryan?
The biggest problem would be dealing with incoming patches that conflict with our internal patches. In particular, anything changing a Makefile would probably cause conflicts that I'd have to manually fix.
Then the question is why do you have to maintain internal patches, please raise the problems, even for things like makefiles we should be able to have a single source version for all platforms.
But, I suppose that would be easier than the effort I'm putting in now, trying to merge the storage patches...
Unfortunately a lot of those are really linux specific, or at least fs-specific, but we should be able to make this modular. libvirt.org is way too old and underpowered to be able to run any virtualization, but if we could have a box with a few QEmu or Xen instances just for compiling the CVS head that would be neat (the irony being of course that we are trying to make those kind of things easier, isn't it !) Daniel -- Red Hat Virtualization group http://redhat.com/virtualization/ Daniel Veillard | virtualization library http://libvirt.org/ veillard@redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
On Tue, Mar 04, 2008 at 01:12:04AM -0500, Daniel Veillard wrote:
We're already doing this internally for Xen. In theory, it shouldn't be too much harder to do the same with libvirt. Ryan?
The biggest problem would be dealing with incoming patches that conflict with our internal patches. In particular, anything changing a Makefile would probably cause conflicts that I'd have to manually fix.
Then the question is why do you have to maintain internal patches, please raise the problems, even for things like makefiles we should be able to have a single source version for all platforms.
We absolutely agree. Unfortunately it takes time to clean up patches and submit them. There are also some things that aren't quite mergable. (For example, in our current bits, 'freecell' just plain didn't work, so we disabled it until we could investigate the real problem). regards john
On Tue, Mar 04, 2008 at 12:33:10PM +0000, John Levon wrote:
On Tue, Mar 04, 2008 at 01:12:04AM -0500, Daniel Veillard wrote:
We're already doing this internally for Xen. In theory, it shouldn't be too much harder to do the same with libvirt. Ryan?
The biggest problem would be dealing with incoming patches that conflict with our internal patches. In particular, anything changing a Makefile would probably cause conflicts that I'd have to manually fix.
Then the question is why do you have to maintain internal patches, please raise the problems, even for things like makefiles we should be able to have a single source version for all platforms.
We absolutely agree. Unfortunately it takes time to clean up patches and submit them. There are also some things that aren't quite mergable. (For example, in our current bits, 'freecell' just plain didn't work, so we disabled it until we could investigate the real problem).
Could be related to the level of xen used, I think they went upstream in 3.2.0, the version we have in RHEL is a backport. Daniel -- Red Hat Virtualization group http://redhat.com/virtualization/ Daniel Veillard | virtualization library http://libvirt.org/ veillard@redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
participants (5)
-
Daniel Veillard -
John Levon -
Pat Wendorf -
Richard W.M. Jones -
Ryan Scott