| Message ID | 4F329327.80609@redhat.com |
|---|---|
| State | New |
| Headers | show |
On 8 February 2012 15:22, Gerd Hoffmann <kraxel@redhat.com> wrote: > On 02/08/12 01:17, Rusty Russell wrote: >> As featured on: >> https://bugs.launchpad.net/qemu-linaro/+bug/928432 >> >> Since we compile with -Werror, the presence of spice headers breaks >> compile. Yet except for x86-64, it doesn't compile, doesn't work, isn't >> supported. See: http://spice-space.org/faq.html > > Outdated. 64bit restrictions are gone, spice server works on 32bit too. > Thats why 32bit spice packages exist in the first place ;) > > Attached patch fixes the warnings. Ping -- there seem to have been a couple of spice patch queue pulls since but did this warning fix patch get lost? thanks -- PMM
On 03/07/12 11:30, Peter Maydell wrote: > On 8 February 2012 15:22, Gerd Hoffmann <kraxel@redhat.com> wrote: >> On 02/08/12 01:17, Rusty Russell wrote: >>> As featured on: >>> https://bugs.launchpad.net/qemu-linaro/+bug/928432 >>> >>> Since we compile with -Werror, the presence of spice headers breaks >>> compile. Yet except for x86-64, it doesn't compile, doesn't work, isn't >>> supported. See: http://spice-space.org/faq.html >> >> Outdated. 64bit restrictions are gone, spice server works on 32bit too. >> Thats why 32bit spice packages exist in the first place ;) >> >> Attached patch fixes the warnings. > > Ping -- there seem to have been a couple of spice patch queue > pulls since but did this warning fix patch get lost? commit f4a8a424fceb0f79bbd9f7ae4285c8a58eb5598e But it still doesn't build indeed. Looks like new warnings sneaked in ... cheers, Gerd
On 7 March 2012 11:38, Gerd Hoffmann <kraxel@redhat.com> wrote: > On 03/07/12 11:30, Peter Maydell wrote: >> Ping -- there seem to have been a couple of spice patch queue >> pulls since but did this warning fix patch get lost? > > commit f4a8a424fceb0f79bbd9f7ae4285c8a58eb5598e Yeah, I just spotted this, not sure why I thought the patch hadn't been applied. Sorry about the noise. > But it still doesn't build indeed. > Looks like new warnings sneaked in ... Hohum :-( -- PMM
On 7 March 2012 11:38, Gerd Hoffmann <kraxel@redhat.com> wrote: > But it still doesn't build indeed. > Looks like new warnings sneaked in ... Actually I get an outright compile error: CC ui/spice-display.o ui/spice-display.c: In function ‘qemu_spice_add_memslot’: ui/spice-display.c:79:42: error: ‘QXL_IO_MEMSLOT_ADD_ASYNC’ undeclared (first use in this function) ui/spice-display.c:79:42: note: each undeclared identifier is reported only once for each function it appears in ui/spice-display.c: In function ‘qemu_spice_create_primary_surface’: ui/spice-display.c:97:42: error: ‘QXL_IO_CREATE_PRIMARY_ASYNC’ undeclared (first use in this function) ui/spice-display.c: In function ‘qemu_spice_destroy_primary_surface’: ui/spice-display.c:110:42: error: ‘QXL_IO_DESTROY_PRIMARY_ASYNC’ undeclared (first use in this function) make: *** [ui/spice-display.o] Error 1 git bisect blames commit 2e1a98c9c "qxl: introduce QXLCookie". Do we need a preprocessor guard so we don't try to use these if the host's spice headers don't support them? (My host is Ubuntu Oneiric with libspice-server-dev 0.8.2-2 and spice-protocol-dev 0.8.0-0ubuntu1.) -- PMM
Hi, > git bisect blames commit 2e1a98c9c "qxl: introduce QXLCookie". > Do we need a preprocessor guard so we don't try to use these > if the host's spice headers don't support them? > (My host is Ubuntu Oneiric with libspice-server-dev 0.8.2-2 > and spice-protocol-dev 0.8.0-0ubuntu1.) Hmm, spice-protocol 0.8.1 adds them. qemu configure has a hard dependency on spice-server 0.8.2 or newer, and I through that automagically pulls in a recent enougth spice-protocol too because it is needed to build spice-server in the first place. Alon? Did I mix up the versioning? Or is this a bug in the ubuntu package dependencies? cheers, Gerd
diff --git a/hw/qxl.c b/hw/qxl.c index 3b5f45a..da7ee1b 100644 --- a/hw/qxl.c +++ b/hw/qxl.c @@ -625,7 +625,7 @@ static void interface_release_resource(QXLInstance *sin, if (ext.group_id == MEMSLOT_GROUP_HOST) { /* host group -> vga mode update request */ - qemu_spice_destroy_update(&qxl->ssd, (void*)ext.info->id); + qemu_spice_destroy_update(&qxl->ssd, (void *)(intptr_t)ext.info->id); return; } @@ -748,7 +748,8 @@ static void interface_async_complete(QXLInstance *sin, uint64_t cookie) qxl->current_async = QXL_UNDEFINED_IO; qemu_mutex_unlock(&qxl->async_lock); - dprint(qxl, 2, "async_complete: %d (%ld) done\n", current_async, cookie); + dprint(qxl, 2, "async_complete: %d (%" PRId64 ") done\n", + current_async, cookie); switch (current_async) { case QXL_IO_CREATE_PRIMARY_ASYNC: qxl_create_guest_primary_complete(qxl); @@ -1017,7 +1018,7 @@ void *qxl_phys2virt(PCIQXLDevice *qxl, QXLPHYSICAL pqxl, int group_id) switch (group_id) { case MEMSLOT_GROUP_HOST: - return (void*)offset; + return (void *)(intptr_t)offset; case MEMSLOT_GROUP_GUEST: PANIC_ON(slot >= NUM_MEMSLOTS); PANIC_ON(!qxl->guest_slots[slot].active);