build glib2 universal binary on PPC

[Ryan Schmidt]

On Mar 5, 2007, at 23:06, Isaac Huang wrote:

> On 3/6/07, Ryan Schmidt 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.

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

Could someone please try to contact this "asingh" then, who wrote the  
glib2 universal installation instructions I posted above from the  
MacFUSE project? I surely don't know what I'm doing, but I assumed  
asingh did.

If "some programs will definitely break," which ones? Do we know of  
any at all? Can someone construct a sample program that will  
demonstrate the failure? I am not a C programmer so I cannot, I would  
just like to see proof that this very simple solution to making the  
universal binary does not work before we embark on a very complicated  
one.


If we're going to be serious about this universal binary business,  
then we will most likely need support within MacPorts for running  
through configure and make multiple times for multiple architectures  
and lipo-ing the result together before make install; it's silly for  
each port that needs it to have to engineer that logic. (Even if we  
get glib2 compiling universal without lipo, there will be other ports  
that still need it).


I have also already investigated compiling a universal binary of  
glib2 twice, once for each arch, and using lipo to combine:

- When cross-compiling glib2 for another architecture (as opposed to  
when building a universal binary, or only a platform-native binary),  
it requires a platform-native copy of glib-genmarshal to exist. So  
that's fun.

- When cross-compiling, autoconf cannot determine a few values, but  
you can supply ./configure with a config.cache file which specifies  
those few values:

glib_cv_stack_grows=${glib_cv_stack_grows=no}
glib_cv_uscore=${glib_cv_uscore=no}
ac_cv_func_posix_getpwuid_r=${ac_cv_func_posix_getpwuid_r=yes}

- I do not know if the endianness issues still remain.