From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:48206) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YgZie-0003vP-E2 for qemu-devel@nongnu.org; Fri, 10 Apr 2015 10:15:44 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YgZic-0005bg-Dy for qemu-devel@nongnu.org; Fri, 10 Apr 2015 10:15:40 -0400 Received: from mx1.redhat.com ([209.132.183.28]:36921) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YgZic-0005bT-1T for qemu-devel@nongnu.org; Fri, 10 Apr 2015 10:15:38 -0400 Message-ID: <5527DB08.8020502@redhat.com> Date: Fri, 10 Apr 2015 10:15:36 -0400 From: John Snow MIME-Version: 1.0 References: <1428615372-615-1-git-send-email-jsnow@redhat.com> <20150410122123.GN23555@stefanha-thinkpad.redhat.com> <1428674350.29519.3.camel@nilsson.home.kraxel.org> In-Reply-To: <1428674350.29519.3.camel@nilsson.home.kraxel.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH] configure: improve multiarch support for pkgconfig List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Gerd Hoffmann , Stefan Hajnoczi Cc: peter.maydell@linaro.org, qemu-devel@nongnu.org, pbonzini@redhat.com On 04/10/2015 09:59 AM, Gerd Hoffmann wrote: > Hi, > >> 32-bit compilation on 64-bit hosts is broken because pkgconfig isn't >> multi-arch aware and selects the 64-bit glibconfig.h header file. That >> file assumes the LP64 data model so guint64 is defined as unsigned long. >> This does not work for 32-bit builds where sizeof(unsigned long) == 4 >> bytes. > > ... there are more effects, like stuff being enabled because 64bit devel > lib is installed even when the 32bit devel lib isn't. > > IMO it is fine to expect users set PKG_CONFIG_LIBDIR accordingly in that > case. It would be very nice though to record this variable (in > config.status maybe?) so it doesn't get lost in case make figures it > should re-run configure because it was changed. > I'm not sure I follow you. What would be wrong with configure re-polling for the correct setting in that case? Unless, perhaps, you are discussing the possibility of losing a user override from the first time they ran configure with PKG_CONFIG_LIBDIR already set to some custom value. > cheers, > Gerd > >