build glib2 universal binary on PPC

[Isaac Huang]

On 3/6/07, Ryan Schmidt <ryandesign at macports.org> wrote:
>
> On Mar 5, 2007, at 06:15, Isaac Huang wrote:
>
> > The glib2 configure script makes conclusions about endianness and
> > atomic operations from host cpu type, and generates headers with such
> > assumptions inside. I've searched this list and someone said glib2
> > needed a patch for this. But I couldn't find this patch, and I also
> > lack enough knowledge about glib2 to fix it myself.
> >
> > Any hint or suggestion is appreciated.
> >
> > BTW, I don't have an Intel Mac so I can't build and lipo.
>
> Well, building twice and using lipo can be possible on a single Mac,
> depending on the software. However, that's not the way that MacPorts
> will attempt to make the universal binary, so it's not relevant here.
>
>
> When I was researching how to compile glib2 universal, I found these
> instructions:
>
> http://code.google.com/p/macfuse/wiki/HOWTO
>
> Specifically this part:
>
> > If you are on a PowerPC Macintosh, comment out one line in
> > config.h: // #define G_ATOMIC_POWERPC 1

I found this too, but I don't think that's sufficient because there's
still the endianness problem. In glibconfig.h for ppc we should have:
......
#define GLONG_TO_BE(val)        ((glong) GINT32_TO_BE (val))
#define GULONG_TO_BE(val)       ((gulong) GUINT32_TO_BE (val))
#define GINT_TO_LE(val)         ((gint) GINT32_TO_LE (val))
#define GUINT_TO_LE(val)        ((guint) GUINT32_TO_LE (val))
#define GINT_TO_BE(val)         ((gint) GINT32_TO_BE (val))
#define GUINT_TO_BE(val)        ((guint) GUINT32_TO_BE (val))
#define G_BYTE_ORDER G_BIG_ENDIAN

If we just get rid of G_ATOMIC_POWERPC, glib2 compiles OK on ppc, but
the resulting  glibconfig.h will assume G_BIG_ENDIAN which won't work
for compiling for i386.

Furthermore, I've discovered this weird thing with glib2 configure
script on my ppc:
ppc/glib-2.12.9 [1044:1]% CFLAGS='-I/opt/local/include'
LDFLAGS='-L/opt/local/lib' ./configure
......
checking whether byte ordering is bigendian... yes
......

Which is correct, _but_:
CFLAGS="-O3 -funroll-loops -fstrict-aliasing -I/opt/local/include
-arch ppc -arch i386 -isysroot /Developer/SDKs/MacOSX10.4u.sdk"
LDFLAGS="-L/opt/local/lib -arch ppc -arch i386  -isysroot
/Developer/SDKs/MacOSX10.4u.sdk" ./configure --prefix=/usr/local
--disable-dependency-tracking
......
checking whether byte ordering is bigendian... no
......

So whenever "-arch ppc -arch i386" is specified the configure script
believes that my ppc iBook isn't bigendian - glib2 still builds OK,
but some programs will definitely break.

> You do that after you run ./configure, and before you run make. You
> can make that one change by hand, or use the attached patch.
>
> It looks like glib uses some assembly code, so if you're building on
> a 32-bit PowerPC Mac, it tries to include 32-bit PowerPC assembly
> even in the Intel executable, which fails.
>
> glib doesn't appear to have any 32-bit Intel assembly code which is
> why the problem shouldn't occur when building a universal binary on a
> 32-bit Intel Mac.
>
> glib does include 64-bit Intel assembly, however, so I wonder if the
> same problem will occur when attempting to build a universal binary
> on a 64-bit Intel Mac, like an Xserve. But I don't have access to an
> Intel Xserve to test it.
>
>
> Jim, you'll probably want to add this patch file to glib2 when
> building the +universal variant.
>
>
>


-- 

Regards, Isaac
()  ascii ribbon campaign - against html e-mail
/\                        - against microsoft attachments