build glib2 universal binary on PPC

Elias Pipping pipping at macports.org
Mon Mar 5 22:00:35 PST 2007


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 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
> _______________________________________________
> macports-dev mailing list
> macports-dev at lists.macosforge.org
> http://lists.macosforge.org/mailman/listinfo/macports-dev




More information about the macports-dev mailing list