All of lore.kernel.org
 help / color / mirror / Atom feed
From: John Snow <jsnow@redhat.com>
To: qemu-devel <qemu-devel@nongnu.org>
Cc: Stefan Hajnoczi <stefanha@redhat.com>
Subject: [Qemu-devel] issue: linking 64bit glib when building for cpu=i386
Date: Thu, 21 Aug 2014 20:10:54 -0400	[thread overview]
Message-ID: <53F68A8E.4060105@redhat.com> (raw)
In-Reply-To: <20140821090328.GA32580@stefanha-thinkpad.redhat.com>

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.

-- 
—js

       reply	other threads:[~2014-08-22  0:11 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <53F55173.6070704@redhat.com>
     [not found] ` <20140821090328.GA32580@stefanha-thinkpad.redhat.com>
2014-08-22  0:10   ` John Snow [this message]
2014-08-22  7:40     ` [Qemu-devel] issue: linking 64bit glib when building for cpu=i386 Markus Armbruster
2014-08-22  7:50     ` Peter Maydell
2014-08-22  8:20     ` Daniel P. Berrange
2014-08-22  8:28       ` Peter Maydell
2014-08-22  8:34         ` Daniel P. Berrange
2014-08-22  8:46           ` Peter Maydell
2014-08-22  9:05       ` Stefan Hajnoczi
2014-09-23 18:52         ` John Snow
2014-09-23 20:20           ` Peter Maydell

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=53F68A8E.4060105@redhat.com \
    --to=jsnow@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=stefanha@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.