I hate to break it to you but I guess glib2 will have to go to the same steps as openssl: 0.) configure 1.) build for ppc 1.1) modify the makefile if needed (make sure BIG ENDIAN is used, comment out assembler inclusion) 1.2) build for ppc 1.3) backup the files from the first run to a temporary location 1.4) cleanup the worksrcpath 2.) build for i386 ... 3.) lipo the results of both runs from the temporary locations together and stage to destroot see http://svn.macports.org/repository/macports/trunk/dports/devel/ openssl/Portfile for an example and http://paste.lisp.org/display/37714,1/raw for a very preliminary idea of what a groupfile might look like. Regards, Elias Pipping On Mar 6, 2007, at 6:06 AM, Isaac Huang wrote:
On 3/6/07, Ryan Schmidt <ryandesign@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 _______________________________________________ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/macports-dev