[Discuss-gnuradio] GNU Radio on MacOS X 10.5 Leopard

[Michael Dickens]

With only a small amount of hacking / patching, I've gotten GNU Radio  
mostly running on MacOS X 10.5 "Leopard".  The WX Scopes don't work  
yet, but the various other WX Widgets look OK and seem to work; I  
will continue looking into the Scope's issue.  Using "nogui" scripts,  
I can verify that USRP <-> USB transport works, and FM reception was  
just fine.  I will write an "install guide" sooner or later on this  
topic, likely once the install of the background libraries /  
includes / applications becomes more reliable / stable.

A few points:

* 10.5 includes XCode 3.0, which uses "i686-apple-darwin9-gcc-4.0.1  
(GCC) 4.0.1 (Apple Inc. build 5465)".  10.4 includes XCode 2.4, which  
uses "i686-apple-darwin8-gcc-4.0.1 (GCC) 4.0.1 (Apple Computer, Inc.  
build 5367)".  Really too bad Apple hasn't updated to at least 4.1 if  
not 4.2.  Ah well; every little bit of progress counts!

* SDCC 2.7.0 as compiled by Apple's GCC doesn't work properly for the  
purposes of GNU Radio's needs for either 10.4 or 10.5 on Intel-Mac's  
only; these work just fine on PPC-Macs at least on 10.4.  SDCC 2.4  
for Intel-Mac provided by the link on the MacInstall page does work  
on both 10.4 and 10.5 for Intel OSX.

* 10.5 includes Python 2.5.1 by default; 10.4 included Python 2.3.5.   
I've created patches for specific MacPorts Portfiles to allow for  
installation using the built-in Python instead of requiring MacPorts  
to install its own version.  The current MacPorts install of Python  
2.5 doesn't include a Framework install, which is required by OSX to  
use any python-based GUI.

* 10.5 does not include (what looks to be) the "standard" suite of 64- 
bit file-access API's ... for example, I think in Linux one would  
have "open64", "close64", "fseek64" and so forth for the 64-bit  
compliant versions, and just "open", "close", and "fseek" for the 32- 
bit versions.  OSX uses the same function names for both versions  
(just "open", "close", and "fseek"), but apparently the actual  
library figures out which version to use (64- or 32-bit).  The only  
exception seems to be the Xstat routines, which have different (and,  
"standard", as above) APIs for both 32 and 64-bit functions (e.g.  
"fstat" and "fstat64").  Apple also does this same trick with  
"off_t" .. there is no "off64_t", just an "off_t" which is 64-bits  
wide under 10.5 (and also in 10.4, at least on Intel-Macs).  I  
learned all of this when getting GUILE 1.8.3 to compile; I have to  
say I like the (presumedly) Linux version better: consistent,  
explicit separation of 32- and 64-bit APIs.

* "make check" fails on 10.5 -only- in qa_goetzel
 Notation: expected ?= actual computed
 + 10.4:
   0.5 == 0.499997220368 within 5 places
   0.0 == 4.00525894099e-06 within 5 places
 + 10.5:
   0.5 != 0.49998197625655755 within 5 places
   0.0 != 8.6014477400182496e-06 within 5 places
  --> I cannot explain why the outputs would be different.  This is  
the -exact- same computer hardware just running the different MacOS X  
versions.

* While it is possible to use 10.5, and will become easier as  
libraries / includes / applications are ported to 10.5, I do not yet  
recommend using it.  10.5 I found unstable for doing much of  
anything; 10.5.1 is much better, but still crashes regularly or just  
hangs.  X11.app, as provided by Apple, has lots of issues due to  
moving from XFree86 to X.org codebase; there is a side effort that  
makes X11 -MUCH- more stable and usable, entirely replacing the  
X11.app provided by Apple.  At the current rate of improvement,  
10.5.4 should be stable enough for general use .. so, another few  
months of suffering for those who have no other choice ;)