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 <[EMAIL PROTECTED]> 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
[email protected]
http://lists.macosforge.org/mailman/listinfo/macports-dev
_______________________________________________
macports-dev mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo/macports-dev
