Re: [Qemu-devel] issue: linking 64bit glib when building for cpu=i386

[Markus Armbruster]

John Snow <address@hidden> writes:

> 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.

>From glibconfig.h:

    typedef signed char gint8;
    typedef unsigned char guint8;
    typedef signed short gint16;
    typedef unsigned short guint16;
    typedef signed int gint32;
    typedef unsigned int guint32;
    typedef signed long gint64;
    typedef unsigned long guint64;

Anyone redoing <stdint.h> in this day and age is a weirdo.

Anyone getting it wrong is a weirdo and a fool.

But getting it wrong in code expressively generated to configure for a
specific platform with a perfectly working <stdint.h>, that's in a
category of weird foolishness of its own.

But wait, it gets even better:

    typedef signed long gssize;
    typedef unsigned long gsize;

Oh yeah, can't rely on size_t, it's been reliably available only since a
decade before GLib was born!

[...]