On 2 Dec 2012, at 19:53, mcquiggi &lt;mcquiggi(a)me.com&gt; wrote: I struggled with this problem myself a while ago. Primarily the problem seems to be caused by the fact that '/opt/local/lib/python2.7/site-packages' is the legacy location for python packages. Modern Python is installed as a frameworks bundle. Frameworks are nothing more that containers of the libraries & associated headers and resources. For Python-2.7 under Macports that is /opt/local/Library/Frameworks/Python.framework/Versions/2.7. OSX always places public bundles in /System/Library/Frameworks. The problem is that /opt/local/lib/python2.7/site-packages is now orphaned and unfortunately osmosdr got built there. The first indication of this is the dreaded: Traceback (most recent call last): File "/Volumes/Store/src/sdr/Radios/fm_rx.py", line 22, in <module> import osmosdr ImportError: No module named osmosdr Launch python itself to see where it is looking: blister:Radios kfs$ python -c 'import sys;from pprint import pprint as pp;pp(sys.path)' ['', '/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python27.zip', '/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7', '/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/plat-darwin', '/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/plat-mac', '/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/plat-mac/lib-scriptpackages', '/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-tk', '/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-old', '/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynload', '/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages', '/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/gtk-2.0', '/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/setuptools-0.6c11-py2.7.egg-info', '/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/wx-2.9.4-osx_cocoa', '/Library/Python/2.7/site-packages'] And it is plain to see that it is NOT looking in the location of where osmosdr is! We'll fix that with: PYTHONPATH=/opt/local/lib/python2.7/site-packages If you run that same enquiry now, you'll see that an extra location is added, that being: '/opt/local/lib/python2.7/site-packages', A side-note here for others with similar problems: I explicitly did not use 'export' commands while testing! If you do, unless you actually unexport them or otherwise purge them each and every time you run a command, you will not actually know what you are testing. Just prefix them to the command as I am doing until you have worked out exactly what is needed. if you now run gnu radio again with a path defined thus: PYTHONPATH=/opt/local/lib/python2.7/site-packages gnuradio-companion fm_rx.grc You get a different error: ImportError: dlopen(/opt/local/lib/python2.7/site-packages/osmosdr/_osmosdr_swig.so, 2): Library not loaded: libgnuradio-osmosdr.0.dylib But this is not the same type of error — this is Python failing to load a library module. On Mac, shared libraries normally end in '.dyld' whereas on other os' they could be .so or .a I believe. And this is where you need to be aware of a slight difference between us and them! OSX uses DYLD_LIBRARY_PATH whereas Linux uses LD_LIBRARY_PATH for supplying library search paths. On Mac we solve this particular problem, which has the same root cause, by adding another hint: PYTHONPATH=/opt/local/lib/python2.7/site-packages \ DYLD_LIBRARY_PATH=/opt/local/lib/python2.7/site-packages:/opt/local/lib \ /Volumes/Store/src/sdr/Radios/fm_rx.py …his leads to a third error: ImportError: dlopen(/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/gnuradio/audio/_audio_swig.so, 2): Symbol not found: _iconv Referenced from: /usr/lib/libcups.2.dylib Expected in: /opt/local/lib/libiconv.2.dylib in /usr/lib/libcups.2.dylib This one is caused by the fact that Apple's libiconv is not a direct replacement for the libiconv in Macports but it is the OSX one that is being used as witnessed by the /usr/lib above. That is easy to fix! We need to persuade the system to use the /opt/local/lib version in preference and that we do with the DYLD_FRAMEWORK_PATH environmental statement above. That leads to the compound launch statement that I got to try. PYTHONPATH=/opt/local/lib/python2.7/site-packages \ DYLD_FALLBACK_LIBRARY_PATH=/opt/local/lib/python2.7/site-packages:/opt/local/lib \ DYLD_FRAMEWORK_PATH=/opt/local/Library/Frameworks \ /Volumes/Store/src/sdr/Radios/fm_rx.py Its well worth looking at 'man dyld' to learn all about the myriad environment variables available. I used DYLD_FALLBACK_LIBRARY instead of DYLD_LIBRARY_PATH for another reason. Its effect is to allow the normal search path to be swept first and then on failure the fallback. You probably can use either. One thing you might find handy for that is yet another environment variable: DYLD_PRINT_LIBRARIES=1 If you set this, you will see exactly where the OS is looking for shared libraries. Now just in case you think I have it all worked out, I haven't! Although I have a fully built system running on Quartz with no X11 in sight, I have some issues to solve of which the primary one is that having built the entire system with clang, I now don't have a very efficient volk! It tells me it wants gcc. Since clang & gcc have a compatible ABI I am hoping to just build that volk stuff using gcc. That and the fact that Everything works except I can't change the frequency of any dongle yet! But thats this weeks problem :-) Regards Ken