3 Dec
2012
3 Dec
'12
9:48 a.m.
On 2 Dec 2012, at 19:53, mcquiggi <mcquiggi(a)me.com> wrote:
IT WORKS!
Explanation of why would be great!!!!
THANKS!
Kevin
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