3:02 p.m.
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
3:43 p.m.
New subject: Support for other platforms (was: Re: [Libvir] OS X Compile Issue)
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
4:47 p.m.
New subject: Support for other platforms (was: Re: [Libvir] OS X Compile Issue)
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
5:27 p.m.
New subject: [Libvir] Re: Support for other platforms
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(a)redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
12:12 a.m.
New subject: [Libvir] Re: Support for other platforms
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(a)redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
6:33 a.m.
New subject: [Libvir] Re: Support for other platforms
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
6:46 a.m.
New subject: [Libvir] Re: Support for other platforms
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(a)redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
6107
days inactive
6108
days old
6 comments
5 participants
participants (5)
-
Daniel Veillard -
John Levon -
Pat Wendorf -
Richard W.M. Jones -
Ryan Scott