After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 542919 - New glib 2.16 release needed for big endian breakage
New glib 2.16 release needed for big endian breakage
Status: RESOLVED FIXED
Product: glib
Classification: Platform
Component: general
2.16.x
Other Linux
: Normal critical
: ---
Assigned To: gtkdev
gtkdev
Depends on:
Blocks:
 
 
Reported: 2008-07-14 12:55 UTC by Sebastian Dröge (slomo)
Modified: 2008-09-14 03:09 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
More portable patch for endianness issue (3.33 KB, patch)
2008-08-14 20:01 UTC, Peter O'Gorman, The Written Word, Inc.
none Details | Review

Description Sebastian Dröge (slomo) 2008-07-14 12:55:37 UTC
Hi,
glib 2.16.4 was released with the broken big endian detection code in configure.in. This results in completely broken glib builds on big endian architectures, which declare themselves as little endian.

Please make a new glib release for this.
Comment 1 Matthias Clasen 2008-07-14 14:25:10 UTC
Just to be clear here: the 'broken bigendian detection code' is in autoconf, not in glib's configure.in.

What you are asking for here is to backport the workaround from trunk, right ?
Comment 2 Sebastian Dröge (slomo) 2008-07-14 14:49:08 UTC
Yes... or to make a new tarball with old autoconf ;)
Comment 3 Matthias Clasen 2008-07-14 16:10:45 UTC
If you need the fix urgently, take the patch from trunk. 

I'll do another stable release at some point before 2.18, but not right now.
Comment 4 Sebastian Dröge (slomo) 2008-07-14 16:37:01 UTC
That's what I've already done, I just filed this bug so other distros who are not aware of the issue don't get a bad surprise :)
Comment 5 Ryan Schmidt 2008-07-16 07:50:23 UTC
The MacPorts project has worked around the issue with this patch:

http://trac.macports.org/browser/trunk/dports/devel/glib2/files/patch-configure.diff?rev=38288

I do not know if this resembles the fix that was made to glib trunk. Is there a URL where I can see that changeset?
Comment 6 Matthias Clasen 2008-07-20 03:58:13 UTC
I've made a 2.16.5 release.
Comment 7 Peter O'Gorman, The Written Word, Inc. 2008-08-14 20:01:10 UTC
Created attachment 116607 [details] [review]
More portable patch for endianness issue

We downloaded 2.16.5 and tried to build it. In configure.in I see:

# check for bytesex stuff
AC_C_BIGENDIAN
if test x$ac_cv_c_bigendian = xuniversal ; then
AC_TRY_COMPILE([#include <endian.h>], [#if __BYTE_ORDER == __BIG_ENDIAN
#else
#error Not a big endian. 
#endif],
    ac_cv_c_bigendian=yes
    ,AC_TRY_COMPILE([#include <endian.h>], [#if __BYTE_ORDER == __LITTLE_ENDIAN
#else
#error Not a little endian. 
#endif],
    ac_cv_c_bigendian=no
    ,AC_MSG_WARN([Could not determine endianness.])))
fi

This is not exactly an ideal patch. As far as I know endian.h is only available on GNU/Linux, so this patch is non-portable (I checked for it on solaris, hpux, aix, osf1, freebsd, irix and darwin).

AC_C_BINGENDIAN is still broken in autoconf git, it tells us that powerpc-ibm-aix is universal, so glib gets things quite wrong for us on AIX. We are working with the autoconf developers to fix that too.

Instead we chose to use the attached patch. It includes sys/types.h and sys/param.h in glibconfig.h if they are available and then uses the results of the macros BYTE_ORDER, LITTLE_ENDIAN, and BIG_ENDIAN to set the G_BYTE_ORDER and related macros. This gets the byte order correct on all our platforms. Then, to make double-sure, we undefine __BIG_ENDIAN__ and __LITTLE_ENDIAN__ which makes sure that AC_C_BIGENDIAN never returns "universal".

Gtk+-2.12.11 still does not build on AIX, or HPUX, but that is another issue.