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
0.5 == 0.499997220368 within 5 places
0.0 == 4.00525894099e-06 within 5 places
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
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