From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:59663) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZWrPy-00044e-Og for qemu-devel@nongnu.org; Tue, 01 Sep 2015 15:40:31 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZWrPv-0001zb-70 for qemu-devel@nongnu.org; Tue, 01 Sep 2015 15:40:30 -0400 Received: from mx1.redhat.com ([209.132.183.28]:37638) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZWrPv-0001yp-2R for qemu-devel@nongnu.org; Tue, 01 Sep 2015 15:40:27 -0400 References: <1441126866-17199-1-git-send-email-mdroth@linux.vnet.ibm.com> <20150901183302.20826.41297@loki> From: John Snow Message-ID: <55E5FF29.4060603@redhat.com> Date: Tue, 1 Sep 2015 15:40:25 -0400 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PULL 00/26] qemu-ga patch queue for 2015-09-01 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Maydell , Michael Roth Cc: QEMU Developers , "Dr. David Alan Gilbert" On 09/01/2015 02:37 PM, Peter Maydell wrote: > On 1 September 2015 at 19:33, Michael Roth wrote: >> Quoting Peter Maydell (2015-09-01 12:12:39) >>> That function wasn't added to glib until 2.28, and our minimum is >>> 2.22. >> >> Sorry for missing this, will send a v2 shortly. >> >> Do you happen to know a way to check/enforce max version levels for glib >> functions? > > The only way I know that works is "do a test compile against 2.22". > >> Apparently there's a GLIB_VERSION_MAX_ALLOWED that serves >> this purpose, but it didn't generate any warnings in this particular >> case: >> >> https://developer.gnome.org/glib/stable/glib-Version-Information.html#GLIB-VERSION-MAX-ALLOWED:CAPS >> >> If we could get that working in tree it might help with these glib compat >> issues (which seem to happen fairly frequently) > > David Gilbert had a look at that a little while back, but it's > trickier than it first looks. > > thanks > -- PMM > I've looked at it before, too. The problem is that we have backported some glib functionality from beyond 2.22 and these macros will fuss at our usage of those functions too, IIRC. We could solve this by *always* using our own version of a glib-provided function if it's from beyond 2.22 and then torpedoing the glib-compat file. --js