Cargo-cult your way through building software
Last week, I wrote about the pain of trying to get certain things to work on my Mac for pseudo-Unixy development. One part of that story involves where I tried to install GNU Radio from Macports but found it was too old to let the Osmocom RTLSDR ($20 TV stick) stuff build. I wound up building it by hand.
I got a fair amount of feedback about that post. Most of it was along the lines of "why don't you just use dtrace", and to that, all I can say is... what do you think dtruss is? Go back and look at the post. I'll wait. Hint: dtruss wants to be run as root, and it's annoying.
But, this post isn't about dtrace. It's about building GNU Radio from source and making it work under Mountain Lion. I'll warn you right now: this is a particularly rough ride through things, and it's probably missing steps where I already had certain things installed. It's definitely not intended to be a complete guide. Instead, think of it as a bunch of notes which might prove helpful during your own bushwhacking session through the build jungle.
First of all, this is built around gnuradio-3.6.1 from the tarball. If there's something newer out there when you read this, or if you're pulling from git, it's anyone's guess as to whether it will apply. Obviously, after you untar it you need to make a build directory, and then from inside of that, you get to run cmake to make the Makefiles -- groan. Set it up so that it bakes in a path which does not taint your system.
Obviously, you need cmake for this. It's in Macports. You'll also need boost and fftw-3-single. This will get you a little ways into it, but then it'll blow up because VOLK wants Cheetah for some reason. So, fine, give it py27-cheetah.
That in and of itself won't let cmake find it, though. Set your PYTHONPATH to the /opt/local/Library/Frameworks/.../site-packages path you get by installing py27-cheetah and run it again.
So now you have to unset all of the insanity that CMake thinks it detected. In the CMakeCache.txt, that means clearing have_mfpu_neon, have_mpopcnt, and have_maltivec. Just change it from "INTERNAL=1" to just "INTERNAL=" and it will forget about them. While you're in there, find HAVE_SHM_OPEN and make it "INTERNAL=1". You'll need it later.
This should build cleanly and install to your separate directory with 'make install'. If not, use a bigger hammer.
So now you need to clone git://git.osmocom.org/rtl-sdr.git into some directory, and do the same thing as above: make a build directory, drop into it, and run the same cmake command with the same prefix. If it complains about not finding libusb, then install libusb-1.0 from ports. Then, you know, make, make install.
Next is gr-osmosdr. Clone it from git://git.osmocom.org/gr-osmosdr and do the same build/cmake-with-prefix thing again, but it'll probably blow up because it can't find gnuradio-core. This is due to the custom install path.
Set PKG_CONFIG_PATH in your environment to whatever path /usr/local/lib/pkgconfig wound up getting in your little prefix path, and try it again. It should work: make, make install.
At this point, you have enough to build and run things like the stuff I've written for my own purposes: simple, solid C++ code which just sits there and does its thing. I have specifically excluded all graphical stuff, and did not make any attempt to get Python support working. All of those layers add ridiculous amounts of cruft to the build process. I don't need it, so I skipped them.
If you want to use gnuradio-companion for its graphical abilities of plugging things together, you have much more work ahead of you, and I do not envy that. Likewise, if you actually want Python stuff to work, you get to fight with things like SWIG. Good luck. I avoided all of that in the interest of my own sanity.
I may have missed some parts where I went into the makefiles (or local annoying equivalent) and hacked 'n' slashed to make it stop building something pointless. Given that all of this happened with the goal of solving my own problems, it would not surprise me if it's totally useless for other people.
Building stuff is easy when you're only solving your own problems. Those brave souls who go out there and make build scripts to do as much as possible for many more users than themselves are the real heroes.
Final note: once you've done this, your programs won't be able to run unless they can find their dynamically linked libraries. DYLD_LIBRARY_PATH must be set to the appropriate directory prior to running one of these programs or it'll bomb when you try to start it. I would advise against putting it in your environment via .profile or similar since suid tools will start complaining.