qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] current git master compile fails on Debian 4.0


From: Erik Rull
Subject: Re: [Qemu-devel] current git master compile fails on Debian 4.0
Date: Tue, 10 Apr 2012 14:31:06 +0200 (CEST)



On April 10, 2012 at 12:57 PM Michael Tokarev <address@hidden> wrote:

> 10.04.2012 14:32, Daniel P. Berrange wrote:
> > On Tue, Apr 10, 2012 at 02:29:56PM +0400, Michael Tokarev wrote:
> >> 10.04.2012 13:18, Erik Rull wrote:
> >>>   Hi all,
> >>>
> >>> on the current git master, I cannot compile any more.
> >>
> >> Debian 4.0 is rather old - it is etch, which was before
> >> lenny which was discontinued about a month ago.  Note
> >> that on etch, for example kvm will not work due to completely
> >> missing kernel support.
> >>
> >>> The error is:
> >>> qapi/qmp-input-visitor.c: In function 'qmp_input_pop':
> >>> qapi/qmp-input-visitor.c:92: error: 'GHashTableIter' undeclared
(first use
> >>> in this function)
>
> > The docs say 2.16:
> >
> > 
http://developer.gnome.org/glib/stable/glib-Hash-Tables.html#g-hash-table-iter-init
>
> And debian 4.0 etch has glib version 2.12.4, so obviously
> that version does not have these declarations.  This is
> the same issue as on RHEL5 which also had 2.12.
>
> >> How about other features (gthread? stuff for the main loop?)
> >> mentioned a few days ago?
> >
> > Check the above docs - IME they're usually pretty good at telling you
> > exactly what version things appeared in.
>
> No, I mean the other way around -- what other features qemu may
> want/need from glib which may be missing in older versions.
>
> A few days ago Paolo posted a patch requiring glib 2.12 (and 2.20
> on windows), so this GHashTableIter thing should either go or
> the lowest required version should be bumped to 2.16.
>
> Thanks!
>
> /mjt
>


Hi all,

upgrading to a newer glib should be possbile - my target system is not the
Debian 4.0, I use it only for compiling and building the target system. My
target is an embedded linux - so it it is possible to point to another glib
version via configure I could just point to that and compile another
version of glib for my target system. So I have it then not installed but
only the binaries available that make / gcc must know.
As long as I do not need another gcc or libc it should be fine.

Best regards,

Erik




reply via email to

[Prev in Thread] Current Thread [Next in Thread]