From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:46940) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XWVCX-0000Fg-Vi for qemu-devel@nongnu.org; Tue, 23 Sep 2014 14:52:42 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XWVCT-0005BD-4L for qemu-devel@nongnu.org; Tue, 23 Sep 2014 14:52:37 -0400 Received: from mx1.redhat.com ([209.132.183.28]:20354) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XWVCS-00057t-TG for qemu-devel@nongnu.org; Tue, 23 Sep 2014 14:52:33 -0400 Message-ID: <5421C162.3080503@redhat.com> Date: Tue, 23 Sep 2014 14:52:18 -0400 From: John Snow MIME-Version: 1.0 References: <53F55173.6070704@redhat.com> <20140821090328.GA32580@stefanha-thinkpad.redhat.com> <53F68A8E.4060105@redhat.com> <20140822082008.GA8447@redhat.com> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] issue: linking 64bit glib when building for cpu=i386 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Stefan Hajnoczi , "Daniel P. Berrange" Cc: "bonzini >> Paolo Bonzini" , qemu-devel , Stefan Hajnoczi On 08/22/2014 05:05 AM, Stefan Hajnoczi wrote: > On Fri, Aug 22, 2014 at 9:20 AM, Daniel P. Berrange wrote: >> On Thu, Aug 21, 2014 at 08:10:54PM -0400, John Snow wrote: >>> I was running a series of tests on 32 and 64 bit hosts to test for >>> endianness and variable width issues when I noticed that I couldn't properly >>> perform a build of "make check" against a 32bit target from a 64bit host: >>> >>> ../../configure --cpu=i386 && make -j4 && make check >>> >>> This produces some warnings in tests-cutils about overflowing variables that >>> are of type guint64. It's been mentioned on the mailing lists before, >>> actually: http://lists.gnu.org/archive/html/qemu-devel/2014-05/msg00452.html >>> >>> The problem is that guint64 is being aliased against "unsigned long", which >>> is only 4 bytes instead of the implied 8. This occurs because we link >>> against the 64bit headers for glib instead of the 32bit ones when we're >>> building for i386 from an x86_64 host. >>> >>> Our include flags wind up looking like: -I/usr/include/glib-2.0 but >>> -I/usr/lib64/glib-2.0/include >>> >>> I was discussing the problem with Stefan: >>> >>> On 08/21/2014 05:03 AM, Stefan Hajnoczi wrote: >>>> The problem is that pkg-config uses libdir=/usr/lib64 by default on >>>> amd64 hosts. It doesn't know that gcc -m32 is being used. >>>> >>>> This results in glib's 64-bit headers being used where guint64 is just >>>> unsigned long. On 32-bit hosts this is incorrect. >>>> >>>> Two workarounds: >>>> >>>> 1. yum install pkgconfig.i686 and run it instead of pkgconfig.x86_64 >>>> >>>> 2. Use the pkg-config --define-variable libdir=/usr/lib option >>>> >>>> You can set PKG_CONFIG=path/to/pkg-config.i686 on QEMU's ./configure >>>> command-line. >>>> >>>> This is all distro-specific :(. Any other solutions? >>>> >>>> Stefan >>>> >>> >>> I am not extremely well versed in configure or pkg-config ninjutsu, but I >>> must imagine that the ARCH/cpu variables we are setting in configure could >>> help us know to call the 32bit pkg-config instead of the native 64bit >>> version and fix this issue. >>> >>> Does anyone have any good ideas? Surely other projects must have run into >>> this elsewhere. >> >> Distros will install pkg-config .pc files for non-native architectures >> in a different location normally. The supported / recommended way to >> tell pkg-config to look in these alternative dirs is to set the env >> variable PKG_CONFIG_LIBDIR. This replaces the built-in default search >> directory that looks for native. >> >> So on a Fedora / RHELL system, to make pkg-config use 32-bit libs you >> want to set >> >> PKG_CONFIG_LIBDIR=/usr/lib/pkgconfig >> >> which replaces the default location of /usr/lib64/pkgconfig. > > Nice, and Paolo sent me an automated way of doing that: > > On Fri, Aug 22, 2014 at 12:14:28AM +0200, Paolo Bonzini wrote: >> You need to set PKG_CONFIG_LIBDIR to >> >> /usr/lib/$MULTILIBDIR/pkgconfig >> >> where MULTILIBDIR is >> >> if $CC -print-multiarch >/dev/null 2>&1; then >> MULTILIBDIR=`$CC -print-multiarch $CFLAGS $CPPFLAGS` >> fi >> if test -z "$MULTILIBDIR"; then >> MULTILIBDIR=`$CC --print-multi-os-directory $CFLAGS $CPPFLAGS` >> fi >> >> This will point at /usr/lib/pkgconfig/glib-2.0.pc instead of >> /usr/lib64/pkgconfig/glib-2.0.pc > > I tested that it works. > > Stefan > A barrier into introducing this into the configuration script is that clang, used on OSX hosts, does not support these print flags. Even worse, clang --print-multi-os-directory produces "x86_64" on Fedora 20, which will lead to an erroneous configuration. So we'll have to look into another way to support cross-compilation for i386 on x86_64 to avoid script breakage on other platforms. Any other ideas? It looks as if there have been proposals in the past to add some multi-arch awareness into pkg-config, but they haven't gone anywhere. So some tool needs to tell pkg-config where to look, but clang is apparently not up to the job. Where does gcc/g++ find out about the lib directories? Or are they baked-in per distro? Any ideas? --j