I've been working on Universal (fat) binaries lately for the upcoming Intel Macs. What fun!
So far I've gotten thru the GRASS libraries, and found a few odd things along the way. Not quite bugs, but should be looked at someday.
Universal binary background: the key is to use a universal Mac OS X SDK, and tell GCC to use that instead of the booted/running system. With GCC 4 (can't use 3.3 for this, or Mac OS 10.3 - 10.4 only) it's like this:
- in gcc/g++, for both compiling and linking, add these options to the gcc/g++ make line:
-arch ppc -arch i386 -isysroot /Developer/SDKs/MacOSX10.4u.sdk
- if one uses ld to link instead of gcc/g++, then the root option is -syslibroot, but it can handle only one arch at a time.
But building both arch's at once is usually not workable because of differing byte orders between the two, or use of libtool with the -MT -MD -MP -MF options, so I end up building the ppc in the normal way, then duplicating that and adding just the -arch i386 and -isysroot options to the copy (manually). Then adjust headers/configs for little-endian. Then I use lipo to merge the two.
So, with GRASS, the byte order doesn't seem to be a big problem - it takes care of endianess either at runtime, or with endian-friendly code. Which brings me to the first problem:
- diglib makefile executes a program it generates at compile time (port_test) to create the portable.h header file to setup architecture-dependent byte-order settings and macros. This fails because I'm building i386 on ppc (like a cross-compiler). I was able to bypass this by copying and editing the ppc portable.h.
Couldn't this be done with runtime code (not the compile-time run) to check byte-order, or would that slow it down too much. Or maybe with a macro flag, like the common WORDS_BIGENDIAN?
- another one (so far) that uses a compile-time generated program to do something at compile-time: lib/fonts/for_grass/splitfont. I think this one is byte-order safe in the output it generates (the installed fonts), so I just copied the compiled program from the ppc build.
I can't think of suggestions for this - I'll just have to deal with it as I already have.
- and finally, lib/vector/rtree/gammavol.c. This uses the gamma() function from libmath in sphere_volume(). The ppc build (native) doesn't have a problem with this, but when linking the rtree lib, the i386 build can't find the _gamma symbol. Even explicity linking in libm doesn't do it. I looked at math.h and see that in the i386 copy of this (but not the ppc copy) gamma() is noted as being 'legacy' and to use tgamma() instead. Both _gamma and _tgamma are in libm (libSystem).
That did the trick - change gamma to tgamma and libgrass_rtree links and finds _tgamma. I don't know if this is a Mac thing for the math lib, or if it's the standard. Maybe someone has a better understanding of this to be able to say if gamma whould be changed to tgamma for all, or conditionalized on a Mac build.
I haven't gotten to the module stuff yet. For now I just needed the libraries for GRASS support in my GIS Libs package. So, I'll followup later with more info. I'll be putting more detailed Universal build info (for more than just GRASS) on my web page soon.
I don't see any problems with building GRASS for Intel Mac OS X on an Intel Mac (so it's a native build). Most of the dependencies are OK as well in this case, but a few (for byte-order specifics) assume Mac=big-endian or will get confused by a Mac system having __I386 defined.
A PPC build on an Intel Mac will probably have similar problems as above.
-----
William Kyngesburye <kyngchaos@kyngchaos.com>
http://www.kyngchaos.com/
Theory of the Universe
There is a theory which states that if ever anyone discovers exactly what the universe is for and why it is here, it will instantly disappear and be replaced by something even more bizarrely inexplicable. There is another theory which states that this has already happened.
-Hitchhiker's Guide to the Galaxy 2nd season intro