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.