From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:50467) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YgZrk-0006JN-Ir for qemu-devel@nongnu.org; Fri, 10 Apr 2015 10:25:08 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YgZrj-0001fD-J0 for qemu-devel@nongnu.org; Fri, 10 Apr 2015 10:25:04 -0400 Received: from mx1.redhat.com ([209.132.183.28]:47090) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YgZrj-0001eN-ES for qemu-devel@nongnu.org; Fri, 10 Apr 2015 10:25:03 -0400 Message-ID: <1428675898.29519.11.camel@nilsson.home.kraxel.org> From: Gerd Hoffmann Date: Fri, 10 Apr 2015 16:24:58 +0200 In-Reply-To: <5527DB08.8020502@redhat.com> References: <1428615372-615-1-git-send-email-jsnow@redhat.com> <20150410122123.GN23555@stefanha-thinkpad.redhat.com> <1428674350.29519.3.camel@nilsson.home.kraxel.org> <5527DB08.8020502@redhat.com> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 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: John Snow Cc: peter.maydell@linaro.org, qemu-devel@nongnu.org, Stefan Hajnoczi , pbonzini@redhat.com On Fr, 2015-04-10 at 10:15 -0400, John Snow wrote: > > 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. Yes, we lose a user override of PKG_CONFIG_LIBDIR today. We should not. Fixing that makes -m32 builds alot less painful already. Trying to automatically set PKG_CONFIG_LIBDIR correctly for -m32 (but as paolo already mentioned only in case it isn't set already) would be sugar on top, no objections to that, but IMO we should get the basics right first. cheers, Gerd