[GRASS5] Mac OS X "Universal" binaries - some problems
woklist at kyngchaos.com
Sat Dec 17 14:47:10 EST 2005
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
- 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
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
A PPC build on an Intel Mac will probably have similar problems as
William Kyngesburye <kyngchaos at 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
-Hitchhiker's Guide to the Galaxy 2nd season intro
More information about the grass-dev