MacPorts and out-of-tree modules


I try to use my out-of-tree modules using OS X 10.8 and the MacPorts
version of gnuradio. I’m not very experienced with OS X. Gnuradio itself
works well when installed using MacPorts.

I configure the out-of-tree modules with

(after having patched GrPython.cmake so that it indeed handles

So, the Python stuff ends up in this esoteric site-packages folder
of /opt/local/lib/…, exactly as core the gnuradio modules do, and the
.dylib file goes to /opt/local/lib, where the core gnuradio stuff seems
reside as well. However, although I can import the swig’d Python
the .dylib is not found. Core gnuradio stuff works. What am I missing

On a side note, how do you configure gnuradio itself if you want to
it yourself instead of getting it from the macports distribution? Are
two options above correct and sufficient?

I’ve got gcc-4.7 from macports, but still the macports-gnuradio gets
compiled with CLANG. Is that normal? :slight_smile:

Hi Pter - It’s been a while since I tried OOT modules with GNU Radio;
it’s certainly possible that the CMake scripts don’t quite work on OSX
right now. I’ll add testing an OOT module to my queue for by

One recommendation is to not use /opt/local to install the module; use
/usr/local instead, or ~/GNURadio/local, or some other non-MacPorts
location. MacPorts is happiest when it has its space undisturbed by
anything else.

CMake should handle setting the libraries and Python scripts correctly,
so then all you should need to do is set PYTHONPATH to point to your new
location’s site-packages directory.

If the Python script is found, but importing it fails because the .dylib
was not found, then you’ll need to check out the .so file that is loaded
by Python; it should be located in the same directory as the Python
scripts. If the file is “”, you can do “otool -L” to see
what libraries the .so file is linked against. If the .dylib is found
but the wrong directory, you can use “install_name_tool” to change it to
what it is supposed to be – and, then please let me know so that I can
fix the issue within CMake.

To build GNU Radio outside of MacPorts, you’ll want to use something
like (all one line; watch for line breaks due to email), assuming from
the top-level GNU Radio source directory:

mkdir build
cd build
CC=/usr/bin/gcc CXX=/usr/bin/g++ cmake
make test

and so forth. CMake does not do a great job finding Python on OSX when
multiple versions are installed; hence all of those defines.

gcc-4.7 from MacPorts cannot be used to compile GNU Radio just yet;
we’re working on that issue. If you want to use something other than
Clang, you can do that via (e.g., if you are using 10.8):

sudo port install gnuradio +full configure.compiler=llvm-gcc-4.2

to use Apple’s Xcode LLVM; for more info, see < > and search for “configure.compiler”.

I hope this helps. I’ll be away for the coming week; hopefully someone
else can jump in if you can’t figure this out. - MLD

Hi Michael,

thanks for the quick and extensive reply.
Using otool I could see that my OOT module got linked to the system
Python instead of the macports Python.
I can cure this by adding -DPYTHON_EXECUTABLE=… etc. to the cmake
command line, and now everything links and runs correctly. I’m very
happy and I can work on my OOT stuff using your port. I also managed to
use llvm instead of Clang. So it seems the same catch applies for OOT
modules as well: I should let cmake explicitly know where to find the
appropriate Python, otherwise everything is just fine.

This single forgotten OOT module (inadvertently linked to system Python
and left installed in /usr/local) broke everything, crashed Python when
I tried to add /usr/local/… to PYTHONPATH.
Best regards,