[GRASS5] Mac OS X "Universal" binaries - some problems

[William Kyngesburye]

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 at 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