All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Michael S. Tsirkin" <mst@redhat.com>
To: Richard Henderson <rth@redhat.com>
Cc: qemu-devel <qemu-devel@nongnu.org>
Subject: Re: [Qemu-devel] [for-1.7] hw/i386/acpi-build.c vs glib-2.12
Date: Tue, 19 Nov 2013 00:57:08 +0200	[thread overview]
Message-ID: <20131118225708.GA1311@redhat.com> (raw)
In-Reply-To: <528A7D64.4020908@redhat.com>

On Tue, Nov 19, 2013 at 06:49:40AM +1000, Richard Henderson wrote:
> hw/i386/acpi-build.c:294:5: error: implicit declaration of function
> ‘g_string_vprintf’ [-Werror=implicit-function-declaration]
>      g_string_vprintf(s, format, args);
> 
> Introduced in 2.14.
> 
> 
> hw/i386/acpi-build.c:427:5: error: implicit declaration of function
> ‘g_array_get_element_size’ [-Werror=implicit-function-declaration]
>      return table->len * g_array_get_element_size(table);
> 
> Introduced in 2.22.
> 
> 
> Our (self-)documented minimums are
> 
> if test "$mingw32" = yes; then
>     # g_poll is required in order to integrate with the glib main loop.
>     glib_req_ver=2.20
> else
>     glib_req_ver=2.12
> fi
> 
> 
> Within unix variants at least, vs(n)printf is likely to be much more portable
> than the glib function.

Hmm. The nice thing with the glib variant is that it allocated memory.
Our specific use is actually 4 bytes so yes, we can make do without.

>  I suspect MinGW has it as well, though I've not checked.
> 
> As for g_array_get_element_size, aren't all of your tables element size 1?
> That's all I can see from acpi_build_tables_init, though I admit to not digging
> deeper.
> 
> 
> 
> r~

There's one with size > 1, though that's not hard to change.

  reply	other threads:[~2013-11-18 22:54 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-11-18 20:49 [Qemu-devel] [for-1.7] hw/i386/acpi-build.c vs glib-2.12 Richard Henderson
2013-11-18 22:57 ` Michael S. Tsirkin [this message]
2013-11-21  9:15 ` Michael S. Tsirkin
2013-11-21 10:09   ` Peter Maydell
2013-11-21 11:25     ` Michael S. Tsirkin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20131118225708.GA1311@redhat.com \
    --to=mst@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=rth@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.