Re: [Qemu-devel] git master build failure in 9pfs
On Fri, 3 Mar 2017 12:28:01 -0600 Eric Blake wrote: > On 03/03/2017 12:15 PM, Greg Kurz wrote: > > > > > O_PATH | O_NOFOLLOW is a special case as described in the last paragraph > > of O_PATH in the man page: > > > > If pathname is a symbolic link and the O_NOFOLLOW flag is > > also > > specified, then the call returns a file descriptor referring > > to > > the symbolic link. This file descriptor can be used as > > the > > dirfd argument in calls to fchownat(2), fstatat(2), > > linkat(2), > > and readlinkat(2) with an empty pathname to have the calls > > oper‐ > > ate on the symbolic link. > > Only when coupled with AT_EMPTY_PATHNAME. Without that additional flag, > then it must be a directory. > And we don't use AT_EMPTY_PATHNAME, so this should work indeed. pgpX_xTfoIOvF.pgp Description: OpenPGP digital signature
Re: [Qemu-devel] git master build failure in 9pfs
On 03/03/2017 12:15 PM, Greg Kurz wrote: > > O_PATH | O_NOFOLLOW is a special case as described in the last paragraph > of O_PATH in the man page: > > If pathname is a symbolic link and the O_NOFOLLOW flag is also > specified, then the call returns a file descriptor referring to > the symbolic link. This file descriptor can be used as the > dirfd argument in calls to fchownat(2), fstatat(2), linkat(2), > and readlinkat(2) with an empty pathname to have the calls oper‐ > ate on the symbolic link. Only when coupled with AT_EMPTY_PATHNAME. Without that additional flag, then it must be a directory. -- Eric Blake eblake redhat com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: [Qemu-devel] git master build failure in 9pfs
On Fri, 3 Mar 2017 12:11:36 -0600 Eric Blake wrote: > On 03/03/2017 10:43 AM, Greg Kurz wrote: > > >>> +#ifndef O_PATH > >>> +#define O_PATH 0 > >>> +#endif > >> > >> Isn't the use of O_PATH required in order to fix the recent > >> security vulnerability in 9p ? If so, then defining it to > >> 0 means the QEMU is silently becoming vulnerable once again > >> which I don't think is a good idea. > >> > > > > O_PATH was supposed to be used as an optimization here, since fds returned > > by > > this function are only passed to openat()... but your comment makes me > > realize > > I inadvertently dropped O_NOFOLLOW between v1 and v2 of the patchset. And > > this > > IS an actual vulnerability issue :) And reading the openat() manpage, I see > > that O_PATH | O_NOFOLLOW doesn't cause openat() to fail, but to return a fd > > pointing to the symlink which is certainly not what I want :) > > Why not? It works, since openat(fd, ...) fails with EBADF if fd is a > symlink rather than a directory. (Well, it SHOULD fail like that, > according to the man page; I need to write a test program and find out > for sure). So you don't have to do any additional syscalls, as your > very next *at call will tell you if you actually got a directory or a > symlink. > O_PATH | O_NOFOLLOW is a special case as described in the last paragraph of O_PATH in the man page: If pathname is a symbolic link and the O_NOFOLLOW flag is also specified, then the call returns a file descriptor referring to the symbolic link. This file descriptor can be used as the dirfd argument in calls to fchownat(2), fstatat(2), linkat(2), and readlinkat(2) with an empty pathname to have the calls oper‐ ate on the symbolic link. Cheers. -- Greg pgpKcfxukjmRF.pgp Description: OpenPGP digital signature
Re: [Qemu-devel] git master build failure in 9pfs
On 03/03/2017 10:43 AM, Greg Kurz wrote: >>> +#ifndef O_PATH >>> +#define O_PATH 0 >>> +#endif >> >> Isn't the use of O_PATH required in order to fix the recent >> security vulnerability in 9p ? If so, then defining it to >> 0 means the QEMU is silently becoming vulnerable once again >> which I don't think is a good idea. >> > > O_PATH was supposed to be used as an optimization here, since fds returned by > this function are only passed to openat()... but your comment makes me realize > I inadvertently dropped O_NOFOLLOW between v1 and v2 of the patchset. And this > IS an actual vulnerability issue :) And reading the openat() manpage, I see > that O_PATH | O_NOFOLLOW doesn't cause openat() to fail, but to return a fd > pointing to the symlink which is certainly not what I want :) Why not? It works, since openat(fd, ...) fails with EBADF if fd is a symlink rather than a directory. (Well, it SHOULD fail like that, according to the man page; I need to write a test program and find out for sure). So you don't have to do any additional syscalls, as your very next *at call will tell you if you actually got a directory or a symlink. -- Eric Blake eblake redhat com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: [Qemu-devel] git master build failure in 9pfs
On 03/03/2017 10:40 AM, Eric Blake wrote: >> Isn't the use of O_PATH required in order to fix the recent >> security vulnerability in 9p ? If so, then defining it to >> 0 means the QEMU is silently becoming vulnerable once again >> which I don't think is a good idea. > > My understanding is that O_PATH is an optimization. It lets openat() > succeed in some places where it would ordinarily fail (for example, it > can be used to open a dir with mode ) - the resulting fd is > limited-use (it cannot be used to read() or write(), but CAN be used as > the relative fd for a subsequent openat(), for example). If you define > O_PATH to 0, then attempts to traverse paths will fail where the could > have otherwise succeeded, but failure is okay (the CVE was that we were > succeeding at opening through a guest-controlled symlink; whether we now > fail or guarantee that we are not going through a symlink is a quality > of implementation, but either way, we are at least immune from > succeeding through a symlink). [I hit send too soon] To put it in perspective, the 9p fixes included code for chmod() that falls back to fchmodat() - but Linux' fchmodat() is broken (it is not POSIX-compliant in that there is no race-free way to use AT_SYMLINK_NOFOLLOW, at least not until Greg gets his kernel patches approved that implement the fchmodat2() syscall [1]). The symptoms are that we now have cases where the guest will get failures where they could have otherwise succeeded if fchmodat() were not broken, but such cases are limited to corners where permissions are overly-tight; in the common case, the permissions will allow opening the file with O_RDONLY or O_WRONLY and fchmod() can be used. So a limited-use fix for the CVE that safely succeeds without symlinks in the common case but fails in the corner case of tight permissions (which is what defining O_PATH to 0 would do) is better than the pre-CVE state of code that succeeds but risks going through a user-controlled symlink. [1] https://lkml.org/lkml/2017/2/28/461 -- Eric Blake eblake redhat com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: [Qemu-devel] git master build failure in 9pfs
On Fri, 3 Mar 2017 16:21:28 + "Daniel P. Berrange" wrote: > On Fri, Mar 03, 2017 at 10:55:01AM -0500, G 3 wrote: > > > > On Mar 3, 2017, at 10:44 AM, Greg Kurz wrote: > > > > > On Fri, 3 Mar 2017 10:28:00 -0500 > > > G 3 wrote: > > > > > > > On Mar 3, 2017, at 9:59 AM, qemu-devel-requ...@nongnu.org wrote: > > > > > On 02/03/17 17:40, Daniel P. Berrange wrote: > > > > > > > > > > > On Thu, Mar 02, 2017 at 05:28:24PM +, Mark Cave-Ayland wrote: > > > > > > > Does anyone else see the following error when trying to build git > > > > > > > master? > > > > > > > > > > > > > > cc -I/home/build/src/qemu/git/qemu/hw/9pfs -Ihw/9pfs > > > > > > > -I/home/build/src/qemu/git/qemu/tcg > > > > > > > -I/home/build/src/qemu/git/qemu/tcg/i386 > > > > > > > -I/home/build/src/qemu/git/qemu/linux-headers > > > > > > > -I/home/build/src/qemu/git/qemu/linux-headers -I. > > > > > > > -I/home/build/src/qemu/git/qemu -I/home/build/src/qemu/git/qemu/ > > > > > > > include > > > > > > > -I/usr/include/pixman-1 > > > > > > > -I/home/build/src/qemu/git/qemu/dtc/libfdt > > > > > > > -Werror -pthread -I/usr/include/glib-2.0 > > > > > > > -I/usr/lib/x86_64-linux-gnu/glib-2.0/include -m64 -mcx16 - > > > > > > > D_GNU_SOURCE > > > > > > > -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes > > > > > > > -Wredundant-decls -Wall -Wundef -Wwrite-strings > > > > > > > -Wmissing-prototypes > > > > > > > -fno-strict-aliasing -fno-common -fwrapv -Wendif-labels > > > > > > > -Wno-missing-include-dirs -Wempty-body -Wnested-externs > > > > > > > -Wformat-security -Wformat-y2k -Winit-self -Wignored-qualifiers > > > > > > > -Wold-style-declaration -Wold-style-definition -Wtype-limits > > > > > > > -fstack-protector-all -I/usr/include/p11-kit-1 > > > > > > > -I/usr/include/libpng12 -I/home/build/src/qemu/git/qemu/tests - > > > > > > > MMD -MP > > > > > > > -MT hw/9pfs/9p-util.o -MF hw/9pfs/9p-util.d -O2 -U_FORTIFY_SOURCE > > > > > > > -D_FORTIFY_SOURCE=2 -g -c -o hw/9pfs/9p-util.o hw/9pfs/9p-util.c > > > > > > > In file included from hw/9pfs/9p-util.c:15:0: > > > > > > > hw/9pfs/9p-util.h: In function ?openat_dir?: > > > > > > > hw/9pfs/9p-util.h:25:57: error: ?O_PATH? undeclared (first use in > > > > > > > this > > > > > > > function) > > > > > > > hw/9pfs/9p-util.h:25:57: note: each undeclared identifier is > > > > > > > reported > > > > > > > only once for each function it appears in > > > > > > > hw/9pfs/9p-util.h:26:1: error: control reaches end of non-void > > > > > > > function > > > > > > > [-Werror=return-type] > > > > > > > > > > > > > > Build platform is Debian Wheezy on an x86_64 host. > > > > > > > > > > > > IIUC, O_PATH was introduced in glibc 2.14 and Wheezy only has 2.13. > > > > > > > > > > > > So unless we want to make this 9pfs code a configurable > > > > > > option, this > > > > > > means Debian Wheezy is no longer a supportable platform for QEMU. > > > > > > > > > > Oh sure, I appreciate that wheezy is getting towards then end of its > > > > > lifetime - it's just a little bit inconvenient to break my > > > > > development > > > > > environment just as we enter 2.9 freeze ;) > > > > > > > > > > If everyone agrees that wheezy is no longer supported after 2.9 > > > > > then I > > > > > can look to upgrading, however my QEMU development is done on my > > > > > laptop > > > > > which is also setup for my day job so it's not a simple case of just > > > > > switching the repository and running dist-upgrade to get me going > > > > > again... > > > > > > > > I remember years ago something like O_PATH was not defined on Mac OS > > > > X, > > > > so the solution was to define the constant as zero. Something like > > > > this: > > > > > > > > #ifndef O_PATH > > > > #define O_PATH 0 > > > > #endif > > > > > > > > Maybe this might work in 9p-util.h. > > > > > > > > > > Yes. Please send a patch and I'll merge it. > > > > > > Cheers. > > > > > > -- > > > Greg > > > > > > Here is the patch. I think we should let Mark or some else test it to see if > > it does fix the problem before a real patch is submitted. > > > > --- > > hw/9pfs/9p-util.h | 4 > > 1 file changed, 4 insertions(+) > > > > diff --git a/hw/9pfs/9p-util.h b/hw/9pfs/9p-util.h > > index 091f3ce..254d2a9 100644 > > --- a/hw/9pfs/9p-util.h > > +++ b/hw/9pfs/9p-util.h > > @@ -13,6 +13,10 @@ > > #ifndef QEMU_9P_UTIL_H > > #define QEMU_9P_UTIL_H > > > > +#ifndef O_PATH > > +#define O_PATH 0 > > +#endif > > Isn't the use of O_PATH required in order to fix the recent > security vulnerability in 9p ? If so, then defining it to > 0 means the QEMU is silently becoming vulnerable once again > which I don't think is a good idea. > O_PATH was supposed to be used as an optimization here, since fds returned by this function are only passed to openat()... but your comment makes me realize I inadvertently dropped O_NOFOLLOW between v1 and v2 of the patchset. And this IS an actual vulnerability issue :) And r
Re: [Qemu-devel] git master build failure in 9pfs
On Fri, Mar 03, 2017 at 10:40:13AM -0600, Eric Blake wrote: > On 03/03/2017 10:21 AM, Daniel P. Berrange wrote: > > >> > >> +#ifndef O_PATH > >> +#define O_PATH 0 > >> +#endif > > > > Isn't the use of O_PATH required in order to fix the recent > > security vulnerability in 9p ? If so, then defining it to > > 0 means the QEMU is silently becoming vulnerable once again > > which I don't think is a good idea. > > My understanding is that O_PATH is an optimization. It lets openat() > succeed in some places where it would ordinarily fail (for example, it > can be used to open a dir with mode ) - the resulting fd is > limited-use (it cannot be used to read() or write(), but CAN be used as > the relative fd for a subsequent openat(), for example). If you define > O_PATH to 0, then attempts to traverse paths will fail where the could > have otherwise succeeded, but failure is okay (the CVE was that we were > succeeding at opening through a guest-controlled symlink; whether we now > fail or guarantee that we are not going through a symlink is a quality > of implementation, but either way, we are at least immune from > succeeding through a symlink). So we're not vulnerable, but we are breaking some valid guest usage. I don't much like the idea of doing that silently, but i guess there's no better alternative. Regards, Daniel -- |: http://berrange.com -o-http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://entangle-photo.org -o-http://search.cpan.org/~danberr/ :|
Re: [Qemu-devel] git master build failure in 9pfs
On 03/03/2017 10:21 AM, Daniel P. Berrange wrote: I remember years ago something like O_PATH was not defined on Mac OS X, so the solution was to define the constant as zero. Something like this: #ifndef O_PATH #define O_PATH 0 #endif Maybe this might work in 9p-util.h. >> >> +#ifndef O_PATH >> +#define O_PATH 0 >> +#endif > > Isn't the use of O_PATH required in order to fix the recent > security vulnerability in 9p ? If so, then defining it to > 0 means the QEMU is silently becoming vulnerable once again > which I don't think is a good idea. My understanding is that O_PATH is an optimization. It lets openat() succeed in some places where it would ordinarily fail (for example, it can be used to open a dir with mode ) - the resulting fd is limited-use (it cannot be used to read() or write(), but CAN be used as the relative fd for a subsequent openat(), for example). If you define O_PATH to 0, then attempts to traverse paths will fail where the could have otherwise succeeded, but failure is okay (the CVE was that we were succeeding at opening through a guest-controlled symlink; whether we now fail or guarantee that we are not going through a symlink is a quality of implementation, but either way, we are at least immune from succeeding through a symlink). -- Eric Blake eblake redhat com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: [Qemu-devel] git master build failure in 9pfs
On Mar 3, 2017, at 11:21 AM, Daniel P. Berrange wrote: On Fri, Mar 03, 2017 at 10:55:01AM -0500, G 3 wrote: On Mar 3, 2017, at 10:44 AM, Greg Kurz wrote: On Fri, 3 Mar 2017 10:28:00 -0500 G 3 wrote: On Mar 3, 2017, at 9:59 AM, qemu-devel-requ...@nongnu.org wrote: On 02/03/17 17:40, Daniel P. Berrange wrote: On Thu, Mar 02, 2017 at 05:28:24PM +, Mark Cave-Ayland wrote: Does anyone else see the following error when trying to build git master? cc -I/home/build/src/qemu/git/qemu/hw/9pfs -Ihw/9pfs -I/home/build/src/qemu/git/qemu/tcg -I/home/build/src/qemu/git/qemu/tcg/i386 -I/home/build/src/qemu/git/qemu/linux-headers -I/home/build/src/qemu/git/qemu/linux-headers -I. -I/home/build/src/qemu/git/qemu -I/home/build/src/qemu/git/qemu/ include -I/usr/include/pixman-1 -I/home/build/src/qemu/git/qemu/dtc/libfdt -Werror -pthread -I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include -m64 -mcx16 - D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes -Wredundant-decls -Wall -Wundef -Wwrite-strings -Wmissing-prototypes -fno-strict-aliasing -fno-common -fwrapv -Wendif-labels -Wno-missing-include-dirs -Wempty-body -Wnested-externs -Wformat-security -Wformat-y2k -Winit-self -Wignored-qualifiers -Wold-style-declaration -Wold-style-definition -Wtype-limits -fstack-protector-all -I/usr/include/p11-kit-1 -I/usr/include/libpng12 -I/home/build/src/qemu/git/qemu/ tests - MMD -MP -MT hw/9pfs/9p-util.o -MF hw/9pfs/9p-util.d -O2 - U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -g -c -o hw/9pfs/9p-util.o hw/9pfs/9p- util.c In file included from hw/9pfs/9p-util.c:15:0: hw/9pfs/9p-util.h: In function ?openat_dir?: hw/9pfs/9p-util.h:25:57: error: ?O_PATH? undeclared (first use in this function) hw/9pfs/9p-util.h:25:57: note: each undeclared identifier is reported only once for each function it appears in hw/9pfs/9p-util.h:26:1: error: control reaches end of non-void function [-Werror=return-type] Build platform is Debian Wheezy on an x86_64 host. IIUC, O_PATH was introduced in glibc 2.14 and Wheezy only has 2.13. So unless we want to make this 9pfs code a configurable option, this means Debian Wheezy is no longer a supportable platform for QEMU. Oh sure, I appreciate that wheezy is getting towards then end of its lifetime - it's just a little bit inconvenient to break my development environment just as we enter 2.9 freeze ;) If everyone agrees that wheezy is no longer supported after 2.9 then I can look to upgrading, however my QEMU development is done on my laptop which is also setup for my day job so it's not a simple case of just switching the repository and running dist-upgrade to get me going again... I remember years ago something like O_PATH was not defined on Mac OS X, so the solution was to define the constant as zero. Something like this: #ifndef O_PATH #define O_PATH 0 #endif Maybe this might work in 9p-util.h. Yes. Please send a patch and I'll merge it. Cheers. -- Greg Here is the patch. I think we should let Mark or some else test it to see if it does fix the problem before a real patch is submitted. --- hw/9pfs/9p-util.h | 4 1 file changed, 4 insertions(+) diff --git a/hw/9pfs/9p-util.h b/hw/9pfs/9p-util.h index 091f3ce..254d2a9 100644 --- a/hw/9pfs/9p-util.h +++ b/hw/9pfs/9p-util.h @@ -13,6 +13,10 @@ #ifndef QEMU_9P_UTIL_H #define QEMU_9P_UTIL_H +#ifndef O_PATH +#define O_PATH 0 +#endif Isn't the use of O_PATH required in order to fix the recent security vulnerability in 9p ? If so, then defining it to 0 means the QEMU is silently becoming vulnerable once again which I don't think is a good idea. I haven't found any documentation that states O_PATH is required to keep things secure. https://lists.gnu.org/archive/html/qemu-devel/2016-08/msg04231.html This post does talk about fixing security issues with the 9pfs protocol, but there is no mention of the 9p-util.h file. Greg Kurz - do you have an option on O_PATH and security?
Re: [Qemu-devel] git master build failure in 9pfs
On Fri, Mar 03, 2017 at 10:55:01AM -0500, G 3 wrote: > > On Mar 3, 2017, at 10:44 AM, Greg Kurz wrote: > > > On Fri, 3 Mar 2017 10:28:00 -0500 > > G 3 wrote: > > > > > On Mar 3, 2017, at 9:59 AM, qemu-devel-requ...@nongnu.org wrote: > > > > On 02/03/17 17:40, Daniel P. Berrange wrote: > > > > > > > > > On Thu, Mar 02, 2017 at 05:28:24PM +, Mark Cave-Ayland wrote: > > > > > > Does anyone else see the following error when trying to build git > > > > > > master? > > > > > > > > > > > > cc -I/home/build/src/qemu/git/qemu/hw/9pfs -Ihw/9pfs > > > > > > -I/home/build/src/qemu/git/qemu/tcg > > > > > > -I/home/build/src/qemu/git/qemu/tcg/i386 > > > > > > -I/home/build/src/qemu/git/qemu/linux-headers > > > > > > -I/home/build/src/qemu/git/qemu/linux-headers -I. > > > > > > -I/home/build/src/qemu/git/qemu -I/home/build/src/qemu/git/qemu/ > > > > > > include > > > > > > -I/usr/include/pixman-1 > > > > > > -I/home/build/src/qemu/git/qemu/dtc/libfdt > > > > > > -Werror -pthread -I/usr/include/glib-2.0 > > > > > > -I/usr/lib/x86_64-linux-gnu/glib-2.0/include -m64 -mcx16 - > > > > > > D_GNU_SOURCE > > > > > > -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes > > > > > > -Wredundant-decls -Wall -Wundef -Wwrite-strings > > > > > > -Wmissing-prototypes > > > > > > -fno-strict-aliasing -fno-common -fwrapv -Wendif-labels > > > > > > -Wno-missing-include-dirs -Wempty-body -Wnested-externs > > > > > > -Wformat-security -Wformat-y2k -Winit-self -Wignored-qualifiers > > > > > > -Wold-style-declaration -Wold-style-definition -Wtype-limits > > > > > > -fstack-protector-all -I/usr/include/p11-kit-1 > > > > > > -I/usr/include/libpng12 -I/home/build/src/qemu/git/qemu/tests - > > > > > > MMD -MP > > > > > > -MT hw/9pfs/9p-util.o -MF hw/9pfs/9p-util.d -O2 -U_FORTIFY_SOURCE > > > > > > -D_FORTIFY_SOURCE=2 -g -c -o hw/9pfs/9p-util.o hw/9pfs/9p-util.c > > > > > > In file included from hw/9pfs/9p-util.c:15:0: > > > > > > hw/9pfs/9p-util.h: In function ?openat_dir?: > > > > > > hw/9pfs/9p-util.h:25:57: error: ?O_PATH? undeclared (first use in > > > > > > this > > > > > > function) > > > > > > hw/9pfs/9p-util.h:25:57: note: each undeclared identifier is > > > > > > reported > > > > > > only once for each function it appears in > > > > > > hw/9pfs/9p-util.h:26:1: error: control reaches end of non-void > > > > > > function > > > > > > [-Werror=return-type] > > > > > > > > > > > > Build platform is Debian Wheezy on an x86_64 host. > > > > > > > > > > IIUC, O_PATH was introduced in glibc 2.14 and Wheezy only has 2.13. > > > > > > > > > > So unless we want to make this 9pfs code a configurable > > > > > option, this > > > > > means Debian Wheezy is no longer a supportable platform for QEMU. > > > > > > > > Oh sure, I appreciate that wheezy is getting towards then end of its > > > > lifetime - it's just a little bit inconvenient to break my > > > > development > > > > environment just as we enter 2.9 freeze ;) > > > > > > > > If everyone agrees that wheezy is no longer supported after 2.9 > > > > then I > > > > can look to upgrading, however my QEMU development is done on my > > > > laptop > > > > which is also setup for my day job so it's not a simple case of just > > > > switching the repository and running dist-upgrade to get me going > > > > again... > > > > > > I remember years ago something like O_PATH was not defined on Mac OS > > > X, > > > so the solution was to define the constant as zero. Something like > > > this: > > > > > > #ifndef O_PATH > > > #define O_PATH 0 > > > #endif > > > > > > Maybe this might work in 9p-util.h. > > > > > > > Yes. Please send a patch and I'll merge it. > > > > Cheers. > > > > -- > > Greg > > > Here is the patch. I think we should let Mark or some else test it to see if > it does fix the problem before a real patch is submitted. > > --- > hw/9pfs/9p-util.h | 4 > 1 file changed, 4 insertions(+) > > diff --git a/hw/9pfs/9p-util.h b/hw/9pfs/9p-util.h > index 091f3ce..254d2a9 100644 > --- a/hw/9pfs/9p-util.h > +++ b/hw/9pfs/9p-util.h > @@ -13,6 +13,10 @@ > #ifndef QEMU_9P_UTIL_H > #define QEMU_9P_UTIL_H > > +#ifndef O_PATH > +#define O_PATH 0 > +#endif Isn't the use of O_PATH required in order to fix the recent security vulnerability in 9p ? If so, then defining it to 0 means the QEMU is silently becoming vulnerable once again which I don't think is a good idea. Regards, Daniel -- |: http://berrange.com -o-http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://entangle-photo.org -o-http://search.cpan.org/~danberr/ :|
Re: [Qemu-devel] git master build failure in 9pfs
On Fri, 3 Mar 2017 15:58:13 +
Peter Maydell wrote:
> On 3 March 2017 at 15:55, G 3 wrote:
> > Here is the patch. I think we should let Mark or some else test it to see if
> > it does fix the problem before a real patch is submitted.
> >
> > ---
> > hw/9pfs/9p-util.h | 4
> > 1 file changed, 4 insertions(+)
>
> We can't take any patch without a Signed-off-by: line, not
> even a three line one.
>
> >
> > diff --git a/hw/9pfs/9p-util.h b/hw/9pfs/9p-util.h
> > index 091f3ce..254d2a9 100644
> > --- a/hw/9pfs/9p-util.h
> > +++ b/hw/9pfs/9p-util.h
> > @@ -13,6 +13,10 @@
> > #ifndef QEMU_9P_UTIL_H
> > #define QEMU_9P_UTIL_H
> >
> > +#ifndef O_PATH
> > +#define O_PATH 0
> > +#endif
>
> Could use a comment explaining why it's OK to define it in
> a way that means it's a no-op on hosts without it.
>
Right. I'll send a patch with an appropriate comment then.
> > +
> > static inline void close_preserve_errno(int fd)
> > {
> > int serrno = errno;
> > --
> > 2.10.2
>
> thanks
> -- PMM
pgp4MROdzv9qO.pgp
Description: OpenPGP digital signature
Re: [Qemu-devel] git master build failure in 9pfs
On Mar 3, 2017, at 10:58 AM, Peter Maydell wrote:
On 3 March 2017 at 15:55, G 3 wrote:
Here is the patch. I think we should let Mark or some else test it
to see if
it does fix the problem before a real patch is submitted.
---
hw/9pfs/9p-util.h | 4
1 file changed, 4 insertions(+)
We can't take any patch without a Signed-off-by: line, not
even a three line one.
This was more of a RFC kind of patch. It is a pre-patch. I honestly
don't know if it will work.
diff --git a/hw/9pfs/9p-util.h b/hw/9pfs/9p-util.h
index 091f3ce..254d2a9 100644
--- a/hw/9pfs/9p-util.h
+++ b/hw/9pfs/9p-util.h
@@ -13,6 +13,10 @@
#ifndef QEMU_9P_UTIL_H
#define QEMU_9P_UTIL_H
+#ifndef O_PATH
+#define O_PATH 0
+#endif
Could use a comment explaining why it's OK to define it in
a way that means it's a no-op on hosts without it.
Ok.
+
static inline void close_preserve_errno(int fd)
{
int serrno = errno;
--
2.10.2
thanks
-- PMM
Thank you.
Re: [Qemu-devel] git master build failure in 9pfs
On 3 March 2017 at 15:55, G 3 wrote:
> Here is the patch. I think we should let Mark or some else test it to see if
> it does fix the problem before a real patch is submitted.
>
> ---
> hw/9pfs/9p-util.h | 4
> 1 file changed, 4 insertions(+)
We can't take any patch without a Signed-off-by: line, not
even a three line one.
>
> diff --git a/hw/9pfs/9p-util.h b/hw/9pfs/9p-util.h
> index 091f3ce..254d2a9 100644
> --- a/hw/9pfs/9p-util.h
> +++ b/hw/9pfs/9p-util.h
> @@ -13,6 +13,10 @@
> #ifndef QEMU_9P_UTIL_H
> #define QEMU_9P_UTIL_H
>
> +#ifndef O_PATH
> +#define O_PATH 0
> +#endif
Could use a comment explaining why it's OK to define it in
a way that means it's a no-op on hosts without it.
> +
> static inline void close_preserve_errno(int fd)
> {
> int serrno = errno;
> --
> 2.10.2
thanks
-- PMM
Re: [Qemu-devel] git master build failure in 9pfs
On Mar 3, 2017, at 10:44 AM, Greg Kurz wrote:
On Fri, 3 Mar 2017 10:28:00 -0500
G 3 wrote:
On Mar 3, 2017, at 9:59 AM, qemu-devel-requ...@nongnu.org wrote:
On 02/03/17 17:40, Daniel P. Berrange wrote:
On Thu, Mar 02, 2017 at 05:28:24PM +, Mark Cave-Ayland wrote:
Does anyone else see the following error when trying to build git
master?
cc -I/home/build/src/qemu/git/qemu/hw/9pfs -Ihw/9pfs
-I/home/build/src/qemu/git/qemu/tcg
-I/home/build/src/qemu/git/qemu/tcg/i386
-I/home/build/src/qemu/git/qemu/linux-headers
-I/home/build/src/qemu/git/qemu/linux-headers -I.
-I/home/build/src/qemu/git/qemu -I/home/build/src/qemu/git/qemu/
include
-I/usr/include/pixman-1 -I/home/build/src/qemu/git/qemu/dtc/
libfdt
-Werror -pthread -I/usr/include/glib-2.0
-I/usr/lib/x86_64-linux-gnu/glib-2.0/include -m64 -mcx16 -
D_GNU_SOURCE
-D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes
-Wredundant-decls -Wall -Wundef -Wwrite-strings -Wmissing-
prototypes
-fno-strict-aliasing -fno-common -fwrapv -Wendif-labels
-Wno-missing-include-dirs -Wempty-body -Wnested-externs
-Wformat-security -Wformat-y2k -Winit-self -Wignored-qualifiers
-Wold-style-declaration -Wold-style-definition -Wtype-limits
-fstack-protector-all -I/usr/include/p11-kit-1
-I/usr/include/libpng12 -I/home/build/src/qemu/git/qemu/tests -
MMD -MP
-MT hw/9pfs/9p-util.o -MF hw/9pfs/9p-util.d -O2 -U_FORTIFY_SOURCE
-D_FORTIFY_SOURCE=2 -g -c -o hw/9pfs/9p-util.o hw/9pfs/9p-util.c
In file included from hw/9pfs/9p-util.c:15:0:
hw/9pfs/9p-util.h: In function ?openat_dir?:
hw/9pfs/9p-util.h:25:57: error: ?O_PATH? undeclared (first use in
this
function)
hw/9pfs/9p-util.h:25:57: note: each undeclared identifier is
reported
only once for each function it appears in
hw/9pfs/9p-util.h:26:1: error: control reaches end of non-void
function
[-Werror=return-type]
Build platform is Debian Wheezy on an x86_64 host.
IIUC, O_PATH was introduced in glibc 2.14 and Wheezy only has 2.13.
So unless we want to make this 9pfs code a configurable option,
this
means Debian Wheezy is no longer a supportable platform for QEMU.
Oh sure, I appreciate that wheezy is getting towards then end of its
lifetime - it's just a little bit inconvenient to break my
development
environment just as we enter 2.9 freeze ;)
If everyone agrees that wheezy is no longer supported after 2.9
then I
can look to upgrading, however my QEMU development is done on my
laptop
which is also setup for my day job so it's not a simple case of just
switching the repository and running dist-upgrade to get me going
again...
I remember years ago something like O_PATH was not defined on Mac
OS X,
so the solution was to define the constant as zero. Something like
this:
#ifndef O_PATH
#define O_PATH 0
#endif
Maybe this might work in 9p-util.h.
Yes. Please send a patch and I'll merge it.
Cheers.
--
Greg
Here is the patch. I think we should let Mark or some else test it to
see if it does fix the problem before a real patch is submitted.
---
hw/9pfs/9p-util.h | 4
1 file changed, 4 insertions(+)
diff --git a/hw/9pfs/9p-util.h b/hw/9pfs/9p-util.h
index 091f3ce..254d2a9 100644
--- a/hw/9pfs/9p-util.h
+++ b/hw/9pfs/9p-util.h
@@ -13,6 +13,10 @@
#ifndef QEMU_9P_UTIL_H
#define QEMU_9P_UTIL_H
+#ifndef O_PATH
+#define O_PATH 0
+#endif
+
static inline void close_preserve_errno(int fd)
{
int serrno = errno;
--
2.10.2
Re: [Qemu-devel] git master build failure in 9pfs
On Fri, 3 Mar 2017 10:28:00 -0500 G 3 wrote: > On Mar 3, 2017, at 9:59 AM, qemu-devel-requ...@nongnu.org wrote: > > On 02/03/17 17:40, Daniel P. Berrange wrote: > > > >> On Thu, Mar 02, 2017 at 05:28:24PM +, Mark Cave-Ayland wrote: > >>> Does anyone else see the following error when trying to build git > >>> master? > >>> > >>> cc -I/home/build/src/qemu/git/qemu/hw/9pfs -Ihw/9pfs > >>> -I/home/build/src/qemu/git/qemu/tcg > >>> -I/home/build/src/qemu/git/qemu/tcg/i386 > >>> -I/home/build/src/qemu/git/qemu/linux-headers > >>> -I/home/build/src/qemu/git/qemu/linux-headers -I. > >>> -I/home/build/src/qemu/git/qemu -I/home/build/src/qemu/git/qemu/ > >>> include > >>> -I/usr/include/pixman-1 -I/home/build/src/qemu/git/qemu/dtc/libfdt > >>> -Werror -pthread -I/usr/include/glib-2.0 > >>> -I/usr/lib/x86_64-linux-gnu/glib-2.0/include -m64 -mcx16 - > >>> D_GNU_SOURCE > >>> -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes > >>> -Wredundant-decls -Wall -Wundef -Wwrite-strings -Wmissing-prototypes > >>> -fno-strict-aliasing -fno-common -fwrapv -Wendif-labels > >>> -Wno-missing-include-dirs -Wempty-body -Wnested-externs > >>> -Wformat-security -Wformat-y2k -Winit-self -Wignored-qualifiers > >>> -Wold-style-declaration -Wold-style-definition -Wtype-limits > >>> -fstack-protector-all -I/usr/include/p11-kit-1 > >>> -I/usr/include/libpng12 -I/home/build/src/qemu/git/qemu/tests - > >>> MMD -MP > >>> -MT hw/9pfs/9p-util.o -MF hw/9pfs/9p-util.d -O2 -U_FORTIFY_SOURCE > >>> -D_FORTIFY_SOURCE=2 -g -c -o hw/9pfs/9p-util.o hw/9pfs/9p-util.c > >>> In file included from hw/9pfs/9p-util.c:15:0: > >>> hw/9pfs/9p-util.h: In function ?openat_dir?: > >>> hw/9pfs/9p-util.h:25:57: error: ?O_PATH? undeclared (first use in > >>> this > >>> function) > >>> hw/9pfs/9p-util.h:25:57: note: each undeclared identifier is > >>> reported > >>> only once for each function it appears in > >>> hw/9pfs/9p-util.h:26:1: error: control reaches end of non-void > >>> function > >>> [-Werror=return-type] > >>> > >>> Build platform is Debian Wheezy on an x86_64 host. > >> > >> IIUC, O_PATH was introduced in glibc 2.14 and Wheezy only has 2.13. > >> > >> So unless we want to make this 9pfs code a configurable option, this > >> means Debian Wheezy is no longer a supportable platform for QEMU. > > > > Oh sure, I appreciate that wheezy is getting towards then end of its > > lifetime - it's just a little bit inconvenient to break my development > > environment just as we enter 2.9 freeze ;) > > > > If everyone agrees that wheezy is no longer supported after 2.9 then I > > can look to upgrading, however my QEMU development is done on my > > laptop > > which is also setup for my day job so it's not a simple case of just > > switching the repository and running dist-upgrade to get me going > > again... > > I remember years ago something like O_PATH was not defined on Mac OS X, > so the solution was to define the constant as zero. Something like this: > > #ifndef O_PATH > #define O_PATH 0 > #endif > > Maybe this might work in 9p-util.h. > Yes. Please send a patch and I'll merge it. Cheers. -- Greg pgpSdWANs6gP2.pgp Description: OpenPGP digital signature
Re: [Qemu-devel] git master build failure in 9pfs
On Thu, 2 Mar 2017 18:10:29 + Peter Maydell wrote: > On 2 March 2017 at 17:40, Daniel P. Berrange wrote: > > On Thu, Mar 02, 2017 at 05:28:24PM +, Mark Cave-Ayland wrote: > >> Build platform is Debian Wheezy on an x86_64 host. > > > > IIUC, O_PATH was introduced in glibc 2.14 and Wheezy only has 2.13. > > > > So unless we want to make this 9pfs code a configurable option, this > > means Debian Wheezy is no longer a supportable platform for QEMU. > > I suspect some of our other supported host OSes still have > glibc 2.13 as well. > > I think we should make this a configure check (assuming O_PATH > is a hard requirement for 9p now). No it's not. It can be defined to 0 if doesn't exist. BTW, I only discover now about this problem... Mark, please Cc me next time for 9p related problems. Cheers. -- Greg > We already only build 9pfs if > we're on a Linux host and have the libcap and libattr libraries available. > > thanks > -- PMM > pgpkORmGA8Igd.pgp Description: OpenPGP digital signature
Re: [Qemu-devel] git master build failure in 9pfs
On Mar 3, 2017, at 9:59 AM, qemu-devel-requ...@nongnu.org wrote: On 02/03/17 17:40, Daniel P. Berrange wrote: On Thu, Mar 02, 2017 at 05:28:24PM +, Mark Cave-Ayland wrote: Does anyone else see the following error when trying to build git master? cc -I/home/build/src/qemu/git/qemu/hw/9pfs -Ihw/9pfs -I/home/build/src/qemu/git/qemu/tcg -I/home/build/src/qemu/git/qemu/tcg/i386 -I/home/build/src/qemu/git/qemu/linux-headers -I/home/build/src/qemu/git/qemu/linux-headers -I. -I/home/build/src/qemu/git/qemu -I/home/build/src/qemu/git/qemu/ include -I/usr/include/pixman-1 -I/home/build/src/qemu/git/qemu/dtc/libfdt -Werror -pthread -I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include -m64 -mcx16 - D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes -Wredundant-decls -Wall -Wundef -Wwrite-strings -Wmissing-prototypes -fno-strict-aliasing -fno-common -fwrapv -Wendif-labels -Wno-missing-include-dirs -Wempty-body -Wnested-externs -Wformat-security -Wformat-y2k -Winit-self -Wignored-qualifiers -Wold-style-declaration -Wold-style-definition -Wtype-limits -fstack-protector-all -I/usr/include/p11-kit-1 -I/usr/include/libpng12 -I/home/build/src/qemu/git/qemu/tests - MMD -MP -MT hw/9pfs/9p-util.o -MF hw/9pfs/9p-util.d -O2 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -g -c -o hw/9pfs/9p-util.o hw/9pfs/9p-util.c In file included from hw/9pfs/9p-util.c:15:0: hw/9pfs/9p-util.h: In function ?openat_dir?: hw/9pfs/9p-util.h:25:57: error: ?O_PATH? undeclared (first use in this function) hw/9pfs/9p-util.h:25:57: note: each undeclared identifier is reported only once for each function it appears in hw/9pfs/9p-util.h:26:1: error: control reaches end of non-void function [-Werror=return-type] Build platform is Debian Wheezy on an x86_64 host. IIUC, O_PATH was introduced in glibc 2.14 and Wheezy only has 2.13. So unless we want to make this 9pfs code a configurable option, this means Debian Wheezy is no longer a supportable platform for QEMU. Oh sure, I appreciate that wheezy is getting towards then end of its lifetime - it's just a little bit inconvenient to break my development environment just as we enter 2.9 freeze ;) If everyone agrees that wheezy is no longer supported after 2.9 then I can look to upgrading, however my QEMU development is done on my laptop which is also setup for my day job so it's not a simple case of just switching the repository and running dist-upgrade to get me going again... I remember years ago something like O_PATH was not defined on Mac OS X, so the solution was to define the constant as zero. Something like this: #ifndef O_PATH #define O_PATH 0 #endif Maybe this might work in 9p-util.h.
Re: [Qemu-devel] git master build failure in 9pfs
On 02/03/17 17:40, Daniel P. Berrange wrote: > On Thu, Mar 02, 2017 at 05:28:24PM +, Mark Cave-Ayland wrote: >> Does anyone else see the following error when trying to build git master? >> >> cc -I/home/build/src/qemu/git/qemu/hw/9pfs -Ihw/9pfs >> -I/home/build/src/qemu/git/qemu/tcg >> -I/home/build/src/qemu/git/qemu/tcg/i386 >> -I/home/build/src/qemu/git/qemu/linux-headers >> -I/home/build/src/qemu/git/qemu/linux-headers -I. >> -I/home/build/src/qemu/git/qemu -I/home/build/src/qemu/git/qemu/include >> -I/usr/include/pixman-1 -I/home/build/src/qemu/git/qemu/dtc/libfdt >> -Werror -pthread -I/usr/include/glib-2.0 >> -I/usr/lib/x86_64-linux-gnu/glib-2.0/include -m64 -mcx16 -D_GNU_SOURCE >> -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes >> -Wredundant-decls -Wall -Wundef -Wwrite-strings -Wmissing-prototypes >> -fno-strict-aliasing -fno-common -fwrapv -Wendif-labels >> -Wno-missing-include-dirs -Wempty-body -Wnested-externs >> -Wformat-security -Wformat-y2k -Winit-self -Wignored-qualifiers >> -Wold-style-declaration -Wold-style-definition -Wtype-limits >> -fstack-protector-all -I/usr/include/p11-kit-1 >> -I/usr/include/libpng12 -I/home/build/src/qemu/git/qemu/tests -MMD -MP >> -MT hw/9pfs/9p-util.o -MF hw/9pfs/9p-util.d -O2 -U_FORTIFY_SOURCE >> -D_FORTIFY_SOURCE=2 -g -c -o hw/9pfs/9p-util.o hw/9pfs/9p-util.c >> In file included from hw/9pfs/9p-util.c:15:0: >> hw/9pfs/9p-util.h: In function ‘openat_dir’: >> hw/9pfs/9p-util.h:25:57: error: ‘O_PATH’ undeclared (first use in this >> function) >> hw/9pfs/9p-util.h:25:57: note: each undeclared identifier is reported >> only once for each function it appears in >> hw/9pfs/9p-util.h:26:1: error: control reaches end of non-void function >> [-Werror=return-type] >> >> Build platform is Debian Wheezy on an x86_64 host. > > IIUC, O_PATH was introduced in glibc 2.14 and Wheezy only has 2.13. > > So unless we want to make this 9pfs code a configurable option, this > means Debian Wheezy is no longer a supportable platform for QEMU. Oh sure, I appreciate that wheezy is getting towards then end of its lifetime - it's just a little bit inconvenient to break my development environment just as we enter 2.9 freeze ;) If everyone agrees that wheezy is no longer supported after 2.9 then I can look to upgrading, however my QEMU development is done on my laptop which is also setup for my day job so it's not a simple case of just switching the repository and running dist-upgrade to get me going again... ATB, Mark.
Re: [Qemu-devel] git master build failure in 9pfs
On Mar 2, 2017, at 1:26 PM, qemu-devel-requ...@nongnu.org wrote: > > Does anyone else see the following error when trying to build git master? > > cc -I/home/build/src/qemu/git/qemu/hw/9pfs -Ihw/9pfs > -I/home/build/src/qemu/git/qemu/tcg > -I/home/build/src/qemu/git/qemu/tcg/i386 > -I/home/build/src/qemu/git/qemu/linux-headers > -I/home/build/src/qemu/git/qemu/linux-headers -I. > -I/home/build/src/qemu/git/qemu -I/home/build/src/qemu/git/qemu/include > -I/usr/include/pixman-1 -I/home/build/src/qemu/git/qemu/dtc/libfdt > -Werror -pthread -I/usr/include/glib-2.0 > -I/usr/lib/x86_64-linux-gnu/glib-2.0/include -m64 -mcx16 -D_GNU_SOURCE > -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes > -Wredundant-decls -Wall -Wundef -Wwrite-strings -Wmissing-prototypes > -fno-strict-aliasing -fno-common -fwrapv -Wendif-labels > -Wno-missing-include-dirs -Wempty-body -Wnested-externs > -Wformat-security -Wformat-y2k -Winit-self -Wignored-qualifiers > -Wold-style-declaration -Wold-style-definition -Wtype-limits > -fstack-protector-all -I/usr/include/p11-kit-1 > -I/usr/include/libpng12 -I/home/build/src/qemu/git/qemu/tests -MMD -MP > -MT hw/9pfs/9p-util.o -MF hw/9pfs/9p-util.d -O2 -U_FORTIFY_SOURCE > -D_FORTIFY_SOURCE=2 -g -c -o hw/9pfs/9p-util.o hw/9pfs/9p-util.c > In file included from hw/9pfs/9p-util.c:15:0: > hw/9pfs/9p-util.h: In function ?openat_dir?: > hw/9pfs/9p-util.h:25:57: error: ?O_PATH? undeclared (first use in this > function) > hw/9pfs/9p-util.h:25:57: note: each undeclared identifier is reported > only once for each function it appears in > hw/9pfs/9p-util.h:26:1: error: control reaches end of non-void function > [-Werror=return-type] > > Build platform is Debian Wheezy on an x86_64 host. > > > ATB, > > Mark. Today when I tried building QEMU I saw this error message that said I was not on a branch. I never saw that before. After a quick 'git checkout master', I was able to 'pull' and 'make' QEMU successfully. I made qemu-system-ppc. Here is the latest commit from git log: commit ecb24d334af1a98ef0329f4b3b0e14ae8cb8770d Merge: 6835504 3db010c Author: Peter Maydell Date: Thu Mar 2 22:06:41 2017 + Which target are you trying to build?
Re: [Qemu-devel] git master build failure in 9pfs
On 2 March 2017 at 17:40, Daniel P. Berrange wrote: > On Thu, Mar 02, 2017 at 05:28:24PM +, Mark Cave-Ayland wrote: >> Build platform is Debian Wheezy on an x86_64 host. > > IIUC, O_PATH was introduced in glibc 2.14 and Wheezy only has 2.13. > > So unless we want to make this 9pfs code a configurable option, this > means Debian Wheezy is no longer a supportable platform for QEMU. I suspect some of our other supported host OSes still have glibc 2.13 as well. I think we should make this a configure check (assuming O_PATH is a hard requirement for 9p now). We already only build 9pfs if we're on a Linux host and have the libcap and libattr libraries available. thanks -- PMM
Re: [Qemu-devel] git master build failure in 9pfs
On Thu, Mar 02, 2017 at 05:28:24PM +, Mark Cave-Ayland wrote: > Does anyone else see the following error when trying to build git master? > > cc -I/home/build/src/qemu/git/qemu/hw/9pfs -Ihw/9pfs > -I/home/build/src/qemu/git/qemu/tcg > -I/home/build/src/qemu/git/qemu/tcg/i386 > -I/home/build/src/qemu/git/qemu/linux-headers > -I/home/build/src/qemu/git/qemu/linux-headers -I. > -I/home/build/src/qemu/git/qemu -I/home/build/src/qemu/git/qemu/include > -I/usr/include/pixman-1 -I/home/build/src/qemu/git/qemu/dtc/libfdt > -Werror -pthread -I/usr/include/glib-2.0 > -I/usr/lib/x86_64-linux-gnu/glib-2.0/include -m64 -mcx16 -D_GNU_SOURCE > -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes > -Wredundant-decls -Wall -Wundef -Wwrite-strings -Wmissing-prototypes > -fno-strict-aliasing -fno-common -fwrapv -Wendif-labels > -Wno-missing-include-dirs -Wempty-body -Wnested-externs > -Wformat-security -Wformat-y2k -Winit-self -Wignored-qualifiers > -Wold-style-declaration -Wold-style-definition -Wtype-limits > -fstack-protector-all -I/usr/include/p11-kit-1 > -I/usr/include/libpng12 -I/home/build/src/qemu/git/qemu/tests -MMD -MP > -MT hw/9pfs/9p-util.o -MF hw/9pfs/9p-util.d -O2 -U_FORTIFY_SOURCE > -D_FORTIFY_SOURCE=2 -g -c -o hw/9pfs/9p-util.o hw/9pfs/9p-util.c > In file included from hw/9pfs/9p-util.c:15:0: > hw/9pfs/9p-util.h: In function ‘openat_dir’: > hw/9pfs/9p-util.h:25:57: error: ‘O_PATH’ undeclared (first use in this > function) > hw/9pfs/9p-util.h:25:57: note: each undeclared identifier is reported > only once for each function it appears in > hw/9pfs/9p-util.h:26:1: error: control reaches end of non-void function > [-Werror=return-type] > > Build platform is Debian Wheezy on an x86_64 host. IIUC, O_PATH was introduced in glibc 2.14 and Wheezy only has 2.13. So unless we want to make this 9pfs code a configurable option, this means Debian Wheezy is no longer a supportable platform for QEMU. Regards, Daniel -- |: http://berrange.com -o-http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://entangle-photo.org -o-http://search.cpan.org/~danberr/ :|
[Qemu-devel] git master build failure in 9pfs
Does anyone else see the following error when trying to build git master? cc -I/home/build/src/qemu/git/qemu/hw/9pfs -Ihw/9pfs -I/home/build/src/qemu/git/qemu/tcg -I/home/build/src/qemu/git/qemu/tcg/i386 -I/home/build/src/qemu/git/qemu/linux-headers -I/home/build/src/qemu/git/qemu/linux-headers -I. -I/home/build/src/qemu/git/qemu -I/home/build/src/qemu/git/qemu/include -I/usr/include/pixman-1 -I/home/build/src/qemu/git/qemu/dtc/libfdt -Werror -pthread -I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include -m64 -mcx16 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes -Wredundant-decls -Wall -Wundef -Wwrite-strings -Wmissing-prototypes -fno-strict-aliasing -fno-common -fwrapv -Wendif-labels -Wno-missing-include-dirs -Wempty-body -Wnested-externs -Wformat-security -Wformat-y2k -Winit-self -Wignored-qualifiers -Wold-style-declaration -Wold-style-definition -Wtype-limits -fstack-protector-all -I/usr/include/p11-kit-1 -I/usr/include/libpng12 -I/home/build/src/qemu/git/qemu/tests -MMD -MP -MT hw/9pfs/9p-util.o -MF hw/9pfs/9p-util.d -O2 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -g -c -o hw/9pfs/9p-util.o hw/9pfs/9p-util.c In file included from hw/9pfs/9p-util.c:15:0: hw/9pfs/9p-util.h: In function ‘openat_dir’: hw/9pfs/9p-util.h:25:57: error: ‘O_PATH’ undeclared (first use in this function) hw/9pfs/9p-util.h:25:57: note: each undeclared identifier is reported only once for each function it appears in hw/9pfs/9p-util.h:26:1: error: control reaches end of non-void function [-Werror=return-type] Build platform is Debian Wheezy on an x86_64 host. ATB, Mark.
Re: [Qemu-devel] git master build failure (migration/colo.c)
On Mon, Oct 31, 2016 at 08:08:46PM +, Mark Cave-Ayland wrote: > I've just done a git pull and get the following build error here: > > cc -I/home/build/src/qemu/git/qemu/tcg > -I/home/build/src/qemu/git/qemu/tcg/i386 > -I/home/build/src/qemu/git/qemu/linux-headers > -I/home/build/src/qemu/git/qemu/linux-headers -I. > -I/home/build/src/qemu/git/qemu -I/home/build/src/qemu/git/qemu/include > -Imigration -Imigration -I/usr/include/pixman-1 > -I/home/build/src/qemu/git/qemu/dtc/libfdt -Werror -pthread > -I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include > -m64 -mcx16 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE > -Wstrict-prototypes -Wredundant-decls -Wall -Wundef -Wwrite-strings > -Wmissing-prototypes -fno-strict-aliasing -fno-common -fwrapv > -Wendif-labels -Wmissing-include-dirs -Wempty-body -Wnested-externs > -Wformat-security -Wformat-y2k -Winit-self -Wignored-qualifiers > -Wold-style-declaration -Wold-style-definition -Wtype-limits > -fstack-protector-all -I/usr/include/p11-kit-1 > -I/usr/include/libpng12 -I/home/build/src/qemu/git/qemu/tests -MMD -MP > -MT migration/colo-failover.o -MF migration/colo-failover.d -O2 > -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -g -c -o > migration/colo-failover.o migration/colo-failover.c > migration/colo.c: In function ‘colo_process_incoming_thread’: > migration/colo.c:448:9: error: ‘request’ may be used uninitialized in > this function [-Werror=maybe-uninitialized] > cc1: all warnings being treated as errors > make: *** [migration/colo.o] Error 1 > make: *** Waiting for unfinished jobs > > Does anyone else see this at all? > I'm not seeing it for later gcc versions (6.2.1), but I was able to reproduce on earlier ones (4.4.7, for instance). I sent a patch out for this. Thanks, Jeff
[Qemu-devel] git master build failure (migration/colo.c)
I've just done a git pull and get the following build error here: cc -I/home/build/src/qemu/git/qemu/tcg -I/home/build/src/qemu/git/qemu/tcg/i386 -I/home/build/src/qemu/git/qemu/linux-headers -I/home/build/src/qemu/git/qemu/linux-headers -I. -I/home/build/src/qemu/git/qemu -I/home/build/src/qemu/git/qemu/include -Imigration -Imigration -I/usr/include/pixman-1 -I/home/build/src/qemu/git/qemu/dtc/libfdt -Werror -pthread -I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include -m64 -mcx16 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes -Wredundant-decls -Wall -Wundef -Wwrite-strings -Wmissing-prototypes -fno-strict-aliasing -fno-common -fwrapv -Wendif-labels -Wmissing-include-dirs -Wempty-body -Wnested-externs -Wformat-security -Wformat-y2k -Winit-self -Wignored-qualifiers -Wold-style-declaration -Wold-style-definition -Wtype-limits -fstack-protector-all -I/usr/include/p11-kit-1 -I/usr/include/libpng12 -I/home/build/src/qemu/git/qemu/tests -MMD -MP -MT migration/colo-failover.o -MF migration/colo-failover.d -O2 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -g -c -o migration/colo-failover.o migration/colo-failover.c migration/colo.c: In function ‘colo_process_incoming_thread’: migration/colo.c:448:9: error: ‘request’ may be used uninitialized in this function [-Werror=maybe-uninitialized] cc1: all warnings being treated as errors make: *** [migration/colo.o] Error 1 make: *** Waiting for unfinished jobs Does anyone else see this at all? ATB, Mark.
Re: [Qemu-devel] git master build failure
On 06/17/16 14:55, Peter Maydell wrote: > On 17 June 2016 at 13:41, Mark Cave-Ayland > wrote: >> Thank you looking into this. I know that some workarounds have been >> applied for similar bugs in Peter's setup, but in general should I >> assume that out-of-the-box Debian oldstable is now no longer supported >> to build QEMU? (I have no stake in this, just took an interest in it for some reason.) > I would kind of prefer us to work around the compiler issue if > it's not too difficult to do so. Otherwise, just configure > with --disable-werror. I agree working it around is preferable, if we can find a deterministic way to do that. I'm afraid it will require someone to look into, and understand, the internal AST representation of gcc (with -fdump-tree-*), and then perturb it through the QEMU source sufficiently. Also, how about filing that backport bug for Debian? If they backport the gcc fix, then the issue is solved -- people can be expected to update their Debian systems fully, before they do any heavy-lifting with them (like building QEMU). Thanks Laszlo
Re: [Qemu-devel] git master build failure
On 17 June 2016 at 13:41, Mark Cave-Ayland wrote: > Thank you looking into this. I know that some workarounds have been > applied for similar bugs in Peter's setup, but in general should I > assume that out-of-the-box Debian oldstable is now no longer supported > to build QEMU? I would kind of prefer us to work around the compiler issue if it's not too difficult to do so. Otherwise, just configure with --disable-werror. thanks -- PMM
Re: [Qemu-devel] git master build failure
On 15/06/16 13:35, Laszlo Ersek wrote:
> On 06/15/16 12:08, Mark Cave-Ayland wrote:
>> On 15/06/16 10:48, Andrew Jones wrote:
>>
>>> On Wed, Jun 15, 2016 at 08:14:18AM +0100, Mark Cave-Ayland wrote:
Hi Peter,
Just to let you know that after pulling git master
(49237b856ae58ee7955be0b959c504c51b014f20) I see the following build
failure here:
>>>
>>> Just pulled and successfully compiled,
>>> configure --target-list=aarch64-softmmu
>>>
>>> And, I'm not sure how it's possible to this warning below. See below
>>>
cc -I/home/build/src/qemu/git/qemu/tcg
-I/home/build/src/qemu/git/qemu/tcg/i386
-I/home/build/src/qemu/git/qemu/linux-headers
-I/home/build/src/qemu/git/qemu/linux-headers -I.
-I/home/build/src/qemu/git/qemu -I/home/build/src/qemu/git/qemu/include
-I/home/build/src/qemu/git/qemu/hw/arm -Ihw/arm -I/usr/include/pixman-1
-I/home/build/src/qemu/git/qemu/dtc/libfdt -Werror -m64 -D_GNU_SOURCE
-D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes
-Wredundant-decls -Wall -Wundef -Wwrite-strings -Wmissing-prototypes
-fno-strict-aliasing -fno-common -Wendif-labels -Wmissing-include-dirs
-Wempty-body -Wnested-externs -Wformat-security -Wformat-y2k -Winit-self
-Wignored-qualifiers -Wold-style-declaration -Wold-style-definition
-Wtype-limits -fstack-protector-all -I/usr/include/p11-kit-1
-I/usr/include/libpng12-I../linux-headers -I..
-I/home/build/src/qemu/git/qemu/target-arm -DNEED_CPU_H
-I/home/build/src/qemu/git/qemu/include -MMD -MP -MT hw/arm/vexpress.o
-MF hw/arm/vexpress.d -O2 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -pthread
-I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include
-g -c -o hw/arm/vexpress.o
/home/build/src/qemu/git/qemu/hw/arm/vexpress.c
cc -I/home/build/src/qemu/git/qemu/tcg
-I/home/build/src/qemu/git/qemu/tcg/i386
-I/home/build/src/qemu/git/qemu/linux-headers
-I/home/build/src/qemu/git/qemu/linux-headers -I.
-I/home/build/src/qemu/git/qemu -I/home/build/src/qemu/git/qemu/include
-I/home/build/src/qemu/git/qemu/hw/arm -Ihw/arm -I/usr/include/pixman-1
-I/home/build/src/qemu/git/qemu/dtc/libfdt -Werror -m64 -D_GNU_SOURCE
-D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes
-Wredundant-decls -Wall -Wundef -Wwrite-strings -Wmissing-prototypes
-fno-strict-aliasing -fno-common -Wendif-labels -Wmissing-include-dirs
-Wempty-body -Wnested-externs -Wformat-security -Wformat-y2k -Winit-self
-Wignored-qualifiers -Wold-style-declaration -Wold-style-definition
-Wtype-limits -fstack-protector-all -I/usr/include/p11-kit-1
-I/usr/include/libpng12-I../linux-headers -I..
-I/home/build/src/qemu/git/qemu/target-arm -DNEED_CPU_H
-I/home/build/src/qemu/git/qemu/include -MMD -MP -MT hw/arm/virt.o -MF
hw/arm/virt.d -O2 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -pthread
-I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include
-g -c -o hw/arm/virt.o /home/build/src/qemu/git/qemu/hw/arm/virt.c
/home/build/src/qemu/git/qemu/hw/arm/virt.c: In function
‘virt_2_6_class_init’:
/home/build/src/qemu/git/qemu/hw/arm/virt.c:1509:5: error: array
subscript is above array bounds [-Werror=array-bounds]
>>>
>>> hw/arm/virt.c:1509 is SET_MACHINE_COMPAT(mc, VIRT_COMPAT_2_6), and
>>> VIRT_COMPAT_2_6 is HW_COMPAT_2_6 (which is currently nothing).
>>>
>>> SET_MACHINE_COMPAT is
>>>
>>> #define SET_MACHINE_COMPAT(m, COMPAT) \
>>> do { \
>>> int i;\
>>> static GlobalProperty props[] = { \
>>> COMPAT \
>>> { /* end of list */ } \
>>> }; \
>>> if (!m->compat_props) { \
>>> m->compat_props = g_array_new(false, false, sizeof(void *));
>>> \
>>> } \
>>> for (i = 0; props[i].driver != NULL; i++) {\
>>> GlobalProperty *prop = &props[i]; \
>>> g_array_append_val(m->compat_props, prop); \
>>> } \
>>> } while (0)
>>>
>>>
>>> so props[] is { {} }, which means props[0].driver == NULL. 0 should
>>> be a valid subscript, and we shouldn't try any others.
>>>
>>> Are you using special config options or a special compiler?
>>>
>>> Thanks,
>>> drew
>>
>> Hi Andrew,
>>
>> Is that from a clean clone of the repository? I wonder if a change to a
>> generated file isn't being picked up somewhere by "make distclean". My
>> standard build script is this:
>>
>> make distclean
>> './configure' '--target-list=x86_64-softmmu sparc64-softmmu
>> sparc-softmmu ppc-softmmu arm-softmmu' '--disable-pie'
>>
>> System is standard Debian wheezy on amd64.
>
> According to , your gcc is 4.7.2
> based (4:4.7.2-1). With a simp
Re: [Qemu-devel] git master build failure
On 06/15/16 12:08, Mark Cave-Ayland wrote:
> On 15/06/16 10:48, Andrew Jones wrote:
>
>> On Wed, Jun 15, 2016 at 08:14:18AM +0100, Mark Cave-Ayland wrote:
>>> Hi Peter,
>>>
>>> Just to let you know that after pulling git master
>>> (49237b856ae58ee7955be0b959c504c51b014f20) I see the following build
>>> failure here:
>>
>> Just pulled and successfully compiled,
>> configure --target-list=aarch64-softmmu
>>
>> And, I'm not sure how it's possible to this warning below. See below
>>
>>>
>>> cc -I/home/build/src/qemu/git/qemu/tcg
>>> -I/home/build/src/qemu/git/qemu/tcg/i386
>>> -I/home/build/src/qemu/git/qemu/linux-headers
>>> -I/home/build/src/qemu/git/qemu/linux-headers -I.
>>> -I/home/build/src/qemu/git/qemu -I/home/build/src/qemu/git/qemu/include
>>> -I/home/build/src/qemu/git/qemu/hw/arm -Ihw/arm -I/usr/include/pixman-1
>>> -I/home/build/src/qemu/git/qemu/dtc/libfdt -Werror -m64 -D_GNU_SOURCE
>>> -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes
>>> -Wredundant-decls -Wall -Wundef -Wwrite-strings -Wmissing-prototypes
>>> -fno-strict-aliasing -fno-common -Wendif-labels -Wmissing-include-dirs
>>> -Wempty-body -Wnested-externs -Wformat-security -Wformat-y2k -Winit-self
>>> -Wignored-qualifiers -Wold-style-declaration -Wold-style-definition
>>> -Wtype-limits -fstack-protector-all -I/usr/include/p11-kit-1
>>> -I/usr/include/libpng12-I../linux-headers -I..
>>> -I/home/build/src/qemu/git/qemu/target-arm -DNEED_CPU_H
>>> -I/home/build/src/qemu/git/qemu/include -MMD -MP -MT hw/arm/vexpress.o
>>> -MF hw/arm/vexpress.d -O2 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -pthread
>>> -I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include
>>> -g -c -o hw/arm/vexpress.o /home/build/src/qemu/git/qemu/hw/arm/vexpress.c
>>> cc -I/home/build/src/qemu/git/qemu/tcg
>>> -I/home/build/src/qemu/git/qemu/tcg/i386
>>> -I/home/build/src/qemu/git/qemu/linux-headers
>>> -I/home/build/src/qemu/git/qemu/linux-headers -I.
>>> -I/home/build/src/qemu/git/qemu -I/home/build/src/qemu/git/qemu/include
>>> -I/home/build/src/qemu/git/qemu/hw/arm -Ihw/arm -I/usr/include/pixman-1
>>> -I/home/build/src/qemu/git/qemu/dtc/libfdt -Werror -m64 -D_GNU_SOURCE
>>> -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes
>>> -Wredundant-decls -Wall -Wundef -Wwrite-strings -Wmissing-prototypes
>>> -fno-strict-aliasing -fno-common -Wendif-labels -Wmissing-include-dirs
>>> -Wempty-body -Wnested-externs -Wformat-security -Wformat-y2k -Winit-self
>>> -Wignored-qualifiers -Wold-style-declaration -Wold-style-definition
>>> -Wtype-limits -fstack-protector-all -I/usr/include/p11-kit-1
>>> -I/usr/include/libpng12-I../linux-headers -I..
>>> -I/home/build/src/qemu/git/qemu/target-arm -DNEED_CPU_H
>>> -I/home/build/src/qemu/git/qemu/include -MMD -MP -MT hw/arm/virt.o -MF
>>> hw/arm/virt.d -O2 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -pthread
>>> -I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include
>>> -g -c -o hw/arm/virt.o /home/build/src/qemu/git/qemu/hw/arm/virt.c
>>> /home/build/src/qemu/git/qemu/hw/arm/virt.c: In function
>>> ‘virt_2_6_class_init’:
>>> /home/build/src/qemu/git/qemu/hw/arm/virt.c:1509:5: error: array
>>> subscript is above array bounds [-Werror=array-bounds]
>>
>> hw/arm/virt.c:1509 is SET_MACHINE_COMPAT(mc, VIRT_COMPAT_2_6), and
>> VIRT_COMPAT_2_6 is HW_COMPAT_2_6 (which is currently nothing).
>>
>> SET_MACHINE_COMPAT is
>>
>> #define SET_MACHINE_COMPAT(m, COMPAT) \
>> do { \
>> int i;\
>> static GlobalProperty props[] = { \
>> COMPAT \
>> { /* end of list */ } \
>> }; \
>> if (!m->compat_props) { \
>> m->compat_props = g_array_new(false, false, sizeof(void *));
>> \
>> } \
>> for (i = 0; props[i].driver != NULL; i++) {\
>> GlobalProperty *prop = &props[i]; \
>> g_array_append_val(m->compat_props, prop); \
>> } \
>> } while (0)
>>
>>
>> so props[] is { {} }, which means props[0].driver == NULL. 0 should
>> be a valid subscript, and we shouldn't try any others.
>>
>> Are you using special config options or a special compiler?
>>
>> Thanks,
>> drew
>
> Hi Andrew,
>
> Is that from a clean clone of the repository? I wonder if a change to a
> generated file isn't being picked up somewhere by "make distclean". My
> standard build script is this:
>
> make distclean
> './configure' '--target-list=x86_64-softmmu sparc64-softmmu
> sparc-softmmu ppc-softmmu arm-softmmu' '--disable-pie'
>
> System is standard Debian wheezy on amd64.
According to , your gcc is 4.7.2
based (4:4.7.2-1). With a simple google search, I found the following
gcc bugs:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=45978
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53
Re: [Qemu-devel] git master build failure
On 15/06/16 12:26, Mark Cave-Ayland wrote: > On 15/06/16 11:23, Andrew Jones wrote: > >>> Is that from a clean clone of the repository? I wonder if a change to a >>> generated file isn't being picked up somewhere by "make distclean". My >>> standard build script is this: >> >> Not a clean clone, but a clean build dir. I build in a separate build dir. >> mkdir builddir >> cd builddir >> ../srcdir/configure ... >> make >> >>> >>> make distclean >>> './configure' '--target-list=x86_64-softmmu sparc64-softmmu >>> sparc-softmmu ppc-softmmu arm-softmmu' '--disable-pie' >> >> Tried this config and still compiles for me. > > I've just tried it again using a git clone into a fresh directory and an > out-of-tree build similar to as you did above and I still get the failure: > > cc -I/home/build/src/qemu/git/x/qemu/tcg > -I/home/build/src/qemu/git/x/qemu/tcg/i386 > -I/home/build/src/qemu/git/x/qemu/linux-headers > -I/home/build/src/qemu/git/x/build/linux-headers -I. > -I/home/build/src/qemu/git/x/qemu > -I/home/build/src/qemu/git/x/qemu/include > -I/home/build/src/qemu/git/x/qemu/target-ppc -Itarget-ppc > -I/usr/include/pixman-1 -I/home/build/src/qemu/git/x/qemu/dtc/libfdt > -Werror -m64 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE > -Wstrict-prototypes -Wredundant-decls -Wall -Wundef -Wwrite-strings > -Wmissing-prototypes -fno-strict-aliasing -fno-common -Wendif-labels > -Wmissing-include-dirs -Wempty-body -Wnested-externs -Wformat-security > -Wformat-y2k -Winit-self -Wignored-qualifiers -Wold-style-declaration > -Wold-style-definition -Wtype-limits -fstack-protector-all > -I/usr/include/p11-kit-1 -I/usr/include/libpng12 > -I../linux-headers -I.. -I/home/build/src/qemu/git/x/qemu/target-ppc > -DNEED_CPU_H -I/home/build/src/qemu/git/x/qemu/include -MMD -MP -MT > target-ppc/timebase_helper.o -MF target-ppc/timebase_helper.d -O2 > -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -pthread -I/usr/include/glib-2.0 > -I/usr/lib/x86_64-linux-gnu/glib-2.0/include -g -c -o > target-ppc/timebase_helper.o > /home/build/src/qemu/git/x/qemu/target-ppc/timebase_helper.c > /home/build/src/qemu/git/x/qemu/hw/arm/virt.c: In function > ‘virt_2_6_class_init’: > /home/build/src/qemu/git/x/qemu/hw/arm/virt.c:1509:5: error: array > subscript is above array bounds [-Werror=array-bounds] > cc1: all warnings being treated as errors > make[1]: *** [hw/arm/virt.o] Error 1 > make[1]: Leaving directory `/home/build/src/qemu/git/x/build/arm-softmmu' > make: *** [subdir-arm-softmmu] Error 2 > > Not sure if it's a contributing factor but my standard make invocation > tries to build with 2 cores once configure has run, i.e. "make V=1 -j2 > install". And here's a log of the build output for the above build (fresh git clone, external build dir): https://www.ilande.co.uk/tmp/qemu/qemu-build-fail.txt. ATB, Mark.
Re: [Qemu-devel] git master build failure
On 15/06/16 11:23, Andrew Jones wrote: >> Is that from a clean clone of the repository? I wonder if a change to a >> generated file isn't being picked up somewhere by "make distclean". My >> standard build script is this: > > Not a clean clone, but a clean build dir. I build in a separate build dir. > mkdir builddir > cd builddir > ../srcdir/configure ... > make > >> >> make distclean >> './configure' '--target-list=x86_64-softmmu sparc64-softmmu >> sparc-softmmu ppc-softmmu arm-softmmu' '--disable-pie' > > Tried this config and still compiles for me. I've just tried it again using a git clone into a fresh directory and an out-of-tree build similar to as you did above and I still get the failure: cc -I/home/build/src/qemu/git/x/qemu/tcg -I/home/build/src/qemu/git/x/qemu/tcg/i386 -I/home/build/src/qemu/git/x/qemu/linux-headers -I/home/build/src/qemu/git/x/build/linux-headers -I. -I/home/build/src/qemu/git/x/qemu -I/home/build/src/qemu/git/x/qemu/include -I/home/build/src/qemu/git/x/qemu/target-ppc -Itarget-ppc -I/usr/include/pixman-1 -I/home/build/src/qemu/git/x/qemu/dtc/libfdt -Werror -m64 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes -Wredundant-decls -Wall -Wundef -Wwrite-strings -Wmissing-prototypes -fno-strict-aliasing -fno-common -Wendif-labels -Wmissing-include-dirs -Wempty-body -Wnested-externs -Wformat-security -Wformat-y2k -Winit-self -Wignored-qualifiers -Wold-style-declaration -Wold-style-definition -Wtype-limits -fstack-protector-all -I/usr/include/p11-kit-1 -I/usr/include/libpng12 -I../linux-headers -I.. -I/home/build/src/qemu/git/x/qemu/target-ppc -DNEED_CPU_H -I/home/build/src/qemu/git/x/qemu/include -MMD -MP -MT target-ppc/timebase_helper.o -MF target-ppc/timebase_helper.d -O2 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -pthread -I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include -g -c -o target-ppc/timebase_helper.o /home/build/src/qemu/git/x/qemu/target-ppc/timebase_helper.c /home/build/src/qemu/git/x/qemu/hw/arm/virt.c: In function ‘virt_2_6_class_init’: /home/build/src/qemu/git/x/qemu/hw/arm/virt.c:1509:5: error: array subscript is above array bounds [-Werror=array-bounds] cc1: all warnings being treated as errors make[1]: *** [hw/arm/virt.o] Error 1 make[1]: Leaving directory `/home/build/src/qemu/git/x/build/arm-softmmu' make: *** [subdir-arm-softmmu] Error 2 Not sure if it's a contributing factor but my standard make invocation tries to build with 2 cores once configure has run, i.e. "make V=1 -j2 install". ATB, Mark.
Re: [Qemu-devel] git master build failure
On Wed, Jun 15, 2016 at 11:08:26AM +0100, Mark Cave-Ayland wrote:
> On 15/06/16 10:48, Andrew Jones wrote:
>
> > On Wed, Jun 15, 2016 at 08:14:18AM +0100, Mark Cave-Ayland wrote:
> >> Hi Peter,
> >>
> >> Just to let you know that after pulling git master
> >> (49237b856ae58ee7955be0b959c504c51b014f20) I see the following build
> >> failure here:
> >
> > Just pulled and successfully compiled,
> > configure --target-list=aarch64-softmmu
> >
> > And, I'm not sure how it's possible to this warning below. See below
> >
> >>
> >> cc -I/home/build/src/qemu/git/qemu/tcg
> >> -I/home/build/src/qemu/git/qemu/tcg/i386
> >> -I/home/build/src/qemu/git/qemu/linux-headers
> >> -I/home/build/src/qemu/git/qemu/linux-headers -I.
> >> -I/home/build/src/qemu/git/qemu -I/home/build/src/qemu/git/qemu/include
> >> -I/home/build/src/qemu/git/qemu/hw/arm -Ihw/arm -I/usr/include/pixman-1
> >> -I/home/build/src/qemu/git/qemu/dtc/libfdt -Werror -m64 -D_GNU_SOURCE
> >> -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes
> >> -Wredundant-decls -Wall -Wundef -Wwrite-strings -Wmissing-prototypes
> >> -fno-strict-aliasing -fno-common -Wendif-labels -Wmissing-include-dirs
> >> -Wempty-body -Wnested-externs -Wformat-security -Wformat-y2k -Winit-self
> >> -Wignored-qualifiers -Wold-style-declaration -Wold-style-definition
> >> -Wtype-limits -fstack-protector-all -I/usr/include/p11-kit-1
> >> -I/usr/include/libpng12-I../linux-headers -I..
> >> -I/home/build/src/qemu/git/qemu/target-arm -DNEED_CPU_H
> >> -I/home/build/src/qemu/git/qemu/include -MMD -MP -MT hw/arm/vexpress.o
> >> -MF hw/arm/vexpress.d -O2 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -pthread
> >> -I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include
> >> -g -c -o hw/arm/vexpress.o
> >> /home/build/src/qemu/git/qemu/hw/arm/vexpress.c
> >> cc -I/home/build/src/qemu/git/qemu/tcg
> >> -I/home/build/src/qemu/git/qemu/tcg/i386
> >> -I/home/build/src/qemu/git/qemu/linux-headers
> >> -I/home/build/src/qemu/git/qemu/linux-headers -I.
> >> -I/home/build/src/qemu/git/qemu -I/home/build/src/qemu/git/qemu/include
> >> -I/home/build/src/qemu/git/qemu/hw/arm -Ihw/arm -I/usr/include/pixman-1
> >> -I/home/build/src/qemu/git/qemu/dtc/libfdt -Werror -m64 -D_GNU_SOURCE
> >> -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes
> >> -Wredundant-decls -Wall -Wundef -Wwrite-strings -Wmissing-prototypes
> >> -fno-strict-aliasing -fno-common -Wendif-labels -Wmissing-include-dirs
> >> -Wempty-body -Wnested-externs -Wformat-security -Wformat-y2k -Winit-self
> >> -Wignored-qualifiers -Wold-style-declaration -Wold-style-definition
> >> -Wtype-limits -fstack-protector-all -I/usr/include/p11-kit-1
> >> -I/usr/include/libpng12-I../linux-headers -I..
> >> -I/home/build/src/qemu/git/qemu/target-arm -DNEED_CPU_H
> >> -I/home/build/src/qemu/git/qemu/include -MMD -MP -MT hw/arm/virt.o -MF
> >> hw/arm/virt.d -O2 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -pthread
> >> -I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include
> >> -g -c -o hw/arm/virt.o /home/build/src/qemu/git/qemu/hw/arm/virt.c
> >> /home/build/src/qemu/git/qemu/hw/arm/virt.c: In function
> >> ‘virt_2_6_class_init’:
> >> /home/build/src/qemu/git/qemu/hw/arm/virt.c:1509:5: error: array
> >> subscript is above array bounds [-Werror=array-bounds]
> >
> > hw/arm/virt.c:1509 is SET_MACHINE_COMPAT(mc, VIRT_COMPAT_2_6), and
> > VIRT_COMPAT_2_6 is HW_COMPAT_2_6 (which is currently nothing).
> >
> > SET_MACHINE_COMPAT is
> >
> > #define SET_MACHINE_COMPAT(m, COMPAT) \
> > do { \
> > int i;\
> > static GlobalProperty props[] = { \
> > COMPAT \
> > { /* end of list */ } \
> > }; \
> > if (!m->compat_props) { \
> > m->compat_props = g_array_new(false, false, sizeof(void *));
> > \
> > } \
> > for (i = 0; props[i].driver != NULL; i++) {\
> > GlobalProperty *prop = &props[i]; \
> > g_array_append_val(m->compat_props, prop); \
> > } \
> > } while (0)
> >
> >
> > so props[] is { {} }, which means props[0].driver == NULL. 0 should
> > be a valid subscript, and we shouldn't try any others.
> >
> > Are you using special config options or a special compiler?
> >
> > Thanks,
> > drew
>
> Hi Andrew,
>
> Is that from a clean clone of the repository? I wonder if a change to a
> generated file isn't being picked up somewhere by "make distclean". My
> standard build script is this:
Not a clean clone, but a clean build dir. I build in a separate build dir.
mkdir builddir
cd builddir
../srcdir/configure ...
make
>
> make distclean
> './configure' '--target-list=x86_64-softmmu sparc64-softmmu
> sparc-softmmu ppc-softmmu arm-softmmu' '--disable-pie'
Tried this config and still compiles for m
Re: [Qemu-devel] git master build failure
On 15/06/16 10:48, Andrew Jones wrote:
> On Wed, Jun 15, 2016 at 08:14:18AM +0100, Mark Cave-Ayland wrote:
>> Hi Peter,
>>
>> Just to let you know that after pulling git master
>> (49237b856ae58ee7955be0b959c504c51b014f20) I see the following build
>> failure here:
>
> Just pulled and successfully compiled,
> configure --target-list=aarch64-softmmu
>
> And, I'm not sure how it's possible to this warning below. See below
>
>>
>> cc -I/home/build/src/qemu/git/qemu/tcg
>> -I/home/build/src/qemu/git/qemu/tcg/i386
>> -I/home/build/src/qemu/git/qemu/linux-headers
>> -I/home/build/src/qemu/git/qemu/linux-headers -I.
>> -I/home/build/src/qemu/git/qemu -I/home/build/src/qemu/git/qemu/include
>> -I/home/build/src/qemu/git/qemu/hw/arm -Ihw/arm -I/usr/include/pixman-1
>> -I/home/build/src/qemu/git/qemu/dtc/libfdt -Werror -m64 -D_GNU_SOURCE
>> -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes
>> -Wredundant-decls -Wall -Wundef -Wwrite-strings -Wmissing-prototypes
>> -fno-strict-aliasing -fno-common -Wendif-labels -Wmissing-include-dirs
>> -Wempty-body -Wnested-externs -Wformat-security -Wformat-y2k -Winit-self
>> -Wignored-qualifiers -Wold-style-declaration -Wold-style-definition
>> -Wtype-limits -fstack-protector-all -I/usr/include/p11-kit-1
>> -I/usr/include/libpng12-I../linux-headers -I..
>> -I/home/build/src/qemu/git/qemu/target-arm -DNEED_CPU_H
>> -I/home/build/src/qemu/git/qemu/include -MMD -MP -MT hw/arm/vexpress.o
>> -MF hw/arm/vexpress.d -O2 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -pthread
>> -I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include
>> -g -c -o hw/arm/vexpress.o /home/build/src/qemu/git/qemu/hw/arm/vexpress.c
>> cc -I/home/build/src/qemu/git/qemu/tcg
>> -I/home/build/src/qemu/git/qemu/tcg/i386
>> -I/home/build/src/qemu/git/qemu/linux-headers
>> -I/home/build/src/qemu/git/qemu/linux-headers -I.
>> -I/home/build/src/qemu/git/qemu -I/home/build/src/qemu/git/qemu/include
>> -I/home/build/src/qemu/git/qemu/hw/arm -Ihw/arm -I/usr/include/pixman-1
>> -I/home/build/src/qemu/git/qemu/dtc/libfdt -Werror -m64 -D_GNU_SOURCE
>> -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes
>> -Wredundant-decls -Wall -Wundef -Wwrite-strings -Wmissing-prototypes
>> -fno-strict-aliasing -fno-common -Wendif-labels -Wmissing-include-dirs
>> -Wempty-body -Wnested-externs -Wformat-security -Wformat-y2k -Winit-self
>> -Wignored-qualifiers -Wold-style-declaration -Wold-style-definition
>> -Wtype-limits -fstack-protector-all -I/usr/include/p11-kit-1
>> -I/usr/include/libpng12-I../linux-headers -I..
>> -I/home/build/src/qemu/git/qemu/target-arm -DNEED_CPU_H
>> -I/home/build/src/qemu/git/qemu/include -MMD -MP -MT hw/arm/virt.o -MF
>> hw/arm/virt.d -O2 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -pthread
>> -I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include
>> -g -c -o hw/arm/virt.o /home/build/src/qemu/git/qemu/hw/arm/virt.c
>> /home/build/src/qemu/git/qemu/hw/arm/virt.c: In function
>> ‘virt_2_6_class_init’:
>> /home/build/src/qemu/git/qemu/hw/arm/virt.c:1509:5: error: array
>> subscript is above array bounds [-Werror=array-bounds]
>
> hw/arm/virt.c:1509 is SET_MACHINE_COMPAT(mc, VIRT_COMPAT_2_6), and
> VIRT_COMPAT_2_6 is HW_COMPAT_2_6 (which is currently nothing).
>
> SET_MACHINE_COMPAT is
>
> #define SET_MACHINE_COMPAT(m, COMPAT) \
> do { \
> int i;\
> static GlobalProperty props[] = { \
> COMPAT \
> { /* end of list */ } \
> }; \
> if (!m->compat_props) { \
> m->compat_props = g_array_new(false, false, sizeof(void *));
> \
> } \
> for (i = 0; props[i].driver != NULL; i++) {\
> GlobalProperty *prop = &props[i]; \
> g_array_append_val(m->compat_props, prop); \
> } \
> } while (0)
>
>
> so props[] is { {} }, which means props[0].driver == NULL. 0 should
> be a valid subscript, and we shouldn't try any others.
>
> Are you using special config options or a special compiler?
>
> Thanks,
> drew
Hi Andrew,
Is that from a clean clone of the repository? I wonder if a change to a
generated file isn't being picked up somewhere by "make distclean". My
standard build script is this:
make distclean
'./configure' '--target-list=x86_64-softmmu sparc64-softmmu
sparc-softmmu ppc-softmmu arm-softmmu' '--disable-pie'
System is standard Debian wheezy on amd64.
ATB,
Mark.
Re: [Qemu-devel] git master build failure
On Wed, Jun 15, 2016 at 08:14:18AM +0100, Mark Cave-Ayland wrote:
> Hi Peter,
>
> Just to let you know that after pulling git master
> (49237b856ae58ee7955be0b959c504c51b014f20) I see the following build
> failure here:
Just pulled and successfully compiled,
configure --target-list=aarch64-softmmu
And, I'm not sure how it's possible to this warning below. See below
>
> cc -I/home/build/src/qemu/git/qemu/tcg
> -I/home/build/src/qemu/git/qemu/tcg/i386
> -I/home/build/src/qemu/git/qemu/linux-headers
> -I/home/build/src/qemu/git/qemu/linux-headers -I.
> -I/home/build/src/qemu/git/qemu -I/home/build/src/qemu/git/qemu/include
> -I/home/build/src/qemu/git/qemu/hw/arm -Ihw/arm -I/usr/include/pixman-1
> -I/home/build/src/qemu/git/qemu/dtc/libfdt -Werror -m64 -D_GNU_SOURCE
> -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes
> -Wredundant-decls -Wall -Wundef -Wwrite-strings -Wmissing-prototypes
> -fno-strict-aliasing -fno-common -Wendif-labels -Wmissing-include-dirs
> -Wempty-body -Wnested-externs -Wformat-security -Wformat-y2k -Winit-self
> -Wignored-qualifiers -Wold-style-declaration -Wold-style-definition
> -Wtype-limits -fstack-protector-all -I/usr/include/p11-kit-1
> -I/usr/include/libpng12-I../linux-headers -I..
> -I/home/build/src/qemu/git/qemu/target-arm -DNEED_CPU_H
> -I/home/build/src/qemu/git/qemu/include -MMD -MP -MT hw/arm/vexpress.o
> -MF hw/arm/vexpress.d -O2 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -pthread
> -I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include
> -g -c -o hw/arm/vexpress.o /home/build/src/qemu/git/qemu/hw/arm/vexpress.c
> cc -I/home/build/src/qemu/git/qemu/tcg
> -I/home/build/src/qemu/git/qemu/tcg/i386
> -I/home/build/src/qemu/git/qemu/linux-headers
> -I/home/build/src/qemu/git/qemu/linux-headers -I.
> -I/home/build/src/qemu/git/qemu -I/home/build/src/qemu/git/qemu/include
> -I/home/build/src/qemu/git/qemu/hw/arm -Ihw/arm -I/usr/include/pixman-1
> -I/home/build/src/qemu/git/qemu/dtc/libfdt -Werror -m64 -D_GNU_SOURCE
> -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes
> -Wredundant-decls -Wall -Wundef -Wwrite-strings -Wmissing-prototypes
> -fno-strict-aliasing -fno-common -Wendif-labels -Wmissing-include-dirs
> -Wempty-body -Wnested-externs -Wformat-security -Wformat-y2k -Winit-self
> -Wignored-qualifiers -Wold-style-declaration -Wold-style-definition
> -Wtype-limits -fstack-protector-all -I/usr/include/p11-kit-1
> -I/usr/include/libpng12-I../linux-headers -I..
> -I/home/build/src/qemu/git/qemu/target-arm -DNEED_CPU_H
> -I/home/build/src/qemu/git/qemu/include -MMD -MP -MT hw/arm/virt.o -MF
> hw/arm/virt.d -O2 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -pthread
> -I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include
> -g -c -o hw/arm/virt.o /home/build/src/qemu/git/qemu/hw/arm/virt.c
> /home/build/src/qemu/git/qemu/hw/arm/virt.c: In function
> ‘virt_2_6_class_init’:
> /home/build/src/qemu/git/qemu/hw/arm/virt.c:1509:5: error: array
> subscript is above array bounds [-Werror=array-bounds]
hw/arm/virt.c:1509 is SET_MACHINE_COMPAT(mc, VIRT_COMPAT_2_6), and
VIRT_COMPAT_2_6 is HW_COMPAT_2_6 (which is currently nothing).
SET_MACHINE_COMPAT is
#define SET_MACHINE_COMPAT(m, COMPAT) \
do { \
int i;\
static GlobalProperty props[] = { \
COMPAT \
{ /* end of list */ } \
}; \
if (!m->compat_props) { \
m->compat_props = g_array_new(false, false, sizeof(void *));
\
} \
for (i = 0; props[i].driver != NULL; i++) {\
GlobalProperty *prop = &props[i]; \
g_array_append_val(m->compat_props, prop); \
} \
} while (0)
so props[] is { {} }, which means props[0].driver == NULL. 0 should
be a valid subscript, and we shouldn't try any others.
Are you using special config options or a special compiler?
Thanks,
drew
> cc1: all warnings being treated as errors
> make[1]: *** [hw/arm/virt.o] Error 1
> make[1]: Leaving directory `/home/build/src/qemu/git/qemu/arm-softmmu'
> make: *** [subdir-arm-softmmu] Error 2
> make: *** Waiting for unfinished jobs
> make[1]: Leaving directory `/home/build/src/qemu/git/qemu/ppc-softmmu'
>
>
> ATB,
>
> Mark.
>
[Qemu-devel] git master build failure
Hi Peter, Just to let you know that after pulling git master (49237b856ae58ee7955be0b959c504c51b014f20) I see the following build failure here: cc -I/home/build/src/qemu/git/qemu/tcg -I/home/build/src/qemu/git/qemu/tcg/i386 -I/home/build/src/qemu/git/qemu/linux-headers -I/home/build/src/qemu/git/qemu/linux-headers -I. -I/home/build/src/qemu/git/qemu -I/home/build/src/qemu/git/qemu/include -I/home/build/src/qemu/git/qemu/hw/arm -Ihw/arm -I/usr/include/pixman-1 -I/home/build/src/qemu/git/qemu/dtc/libfdt -Werror -m64 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes -Wredundant-decls -Wall -Wundef -Wwrite-strings -Wmissing-prototypes -fno-strict-aliasing -fno-common -Wendif-labels -Wmissing-include-dirs -Wempty-body -Wnested-externs -Wformat-security -Wformat-y2k -Winit-self -Wignored-qualifiers -Wold-style-declaration -Wold-style-definition -Wtype-limits -fstack-protector-all -I/usr/include/p11-kit-1 -I/usr/include/libpng12-I../linux-headers -I.. -I/home/build/src/qemu/git/qemu/target-arm -DNEED_CPU_H -I/home/build/src/qemu/git/qemu/include -MMD -MP -MT hw/arm/vexpress.o -MF hw/arm/vexpress.d -O2 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -pthread -I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include -g -c -o hw/arm/vexpress.o /home/build/src/qemu/git/qemu/hw/arm/vexpress.c cc -I/home/build/src/qemu/git/qemu/tcg -I/home/build/src/qemu/git/qemu/tcg/i386 -I/home/build/src/qemu/git/qemu/linux-headers -I/home/build/src/qemu/git/qemu/linux-headers -I. -I/home/build/src/qemu/git/qemu -I/home/build/src/qemu/git/qemu/include -I/home/build/src/qemu/git/qemu/hw/arm -Ihw/arm -I/usr/include/pixman-1 -I/home/build/src/qemu/git/qemu/dtc/libfdt -Werror -m64 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes -Wredundant-decls -Wall -Wundef -Wwrite-strings -Wmissing-prototypes -fno-strict-aliasing -fno-common -Wendif-labels -Wmissing-include-dirs -Wempty-body -Wnested-externs -Wformat-security -Wformat-y2k -Winit-self -Wignored-qualifiers -Wold-style-declaration -Wold-style-definition -Wtype-limits -fstack-protector-all -I/usr/include/p11-kit-1 -I/usr/include/libpng12-I../linux-headers -I.. -I/home/build/src/qemu/git/qemu/target-arm -DNEED_CPU_H -I/home/build/src/qemu/git/qemu/include -MMD -MP -MT hw/arm/virt.o -MF hw/arm/virt.d -O2 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -pthread -I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include -g -c -o hw/arm/virt.o /home/build/src/qemu/git/qemu/hw/arm/virt.c /home/build/src/qemu/git/qemu/hw/arm/virt.c: In function ‘virt_2_6_class_init’: /home/build/src/qemu/git/qemu/hw/arm/virt.c:1509:5: error: array subscript is above array bounds [-Werror=array-bounds] cc1: all warnings being treated as errors make[1]: *** [hw/arm/virt.o] Error 1 make[1]: Leaving directory `/home/build/src/qemu/git/qemu/arm-softmmu' make: *** [subdir-arm-softmmu] Error 2 make: *** Waiting for unfinished jobs make[1]: Leaving directory `/home/build/src/qemu/git/qemu/ppc-softmmu' ATB, Mark.
