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. Thanks, Isaac -- Regards, Isaac () ascii ribbon campaign - against html e-mail /\ - against microsoft attachments
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
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.
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
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
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.
On Mar 6, 2007, at 00:00, Elias Pipping wrote:
I hate to break it to you but I guess glib2 will have to go to the same steps as openssl:
I have to agree with the earlier post in another thread that the openssl port has become quite a mess with this universal stuff, and I think it would be wiser if no other ports copied that code. Copying code means you've missed a chance for creating a reusable function. Someone who understands all of what was written in the openssl port (and I don't, because I just glanced at it) should figure out how to make useful reusable functions that can be incorporated into the base of MacPorts, rather than duplicate most of it in several other ports, each time making ultimate cleanup of the situation more involved.
that's why i added a link to this paste in my mail ;) http://paste.lisp.org/display/37714,1/raw assuming nothing in the very core of macports is touched (so there's nothing like "build1, build2" or anything) this is what's reusable: * the backup function that is passed an architecture and works on a filelist * the invocation 'build - backup' (goes into pre-build, post-build) so... what's the actual difference between these ports (that use lipo to build universal) is: * the step that modifies the configuration for each architecture before building * the file list the problem with the file list is: in order to allow creating it through globbing instead of having a static list for every port it would have to be created between the build- and the backup-step. because the post-configure step needs to be done twice and we have something like variable - constant - variable - constant the post-configure step of the second build phase needs to go into 'build' so it's basically: variable: post-configure {foo - whatever needs to be done for the first run} constant: pre-build (comes from the groupfile) variable: build {bar - whatever needs to be done for the second run} constant: post-build (comes from the groupfile, too) in order to allow splitting up the build- and the backup-step for the filelist that would require the invocation of the backup step to go into build, instead of pre-build (not a problem) and post-post-build (there's no such thing, is there?). since after post-build comes pre- destroot and such a step shouldn't go into the destroot step that'd require restructuring of the whole configure-build-destroot idea with pre- and post-. so umm... what do we do? Regards, Elias Pipping On Mar 6, 2007, at 8:00 AM, Ryan Schmidt wrote:
On Mar 6, 2007, at 00:00, Elias Pipping wrote:
I hate to break it to you but I guess glib2 will have to go to the same steps as openssl:
I have to agree with the earlier post in another thread that the openssl port has become quite a mess with this universal stuff, and I think it would be wiser if no other ports copied that code. Copying code means you've missed a chance for creating a reusable function. Someone who understands all of what was written in the openssl port (and I don't, because I just glanced at it) should figure out how to make useful reusable functions that can be incorporated into the base of MacPorts, rather than duplicate most of it in several other ports, each time making ultimate cleanup of the situation more involved.
participants (3)
-
Elias Pipping
-
Isaac Huang
-
Ryan Schmidt