Hi Michael - I’m glad you’re having success with at least the MacPorts part of
and, thanks! I’m glad to be back on top of UHD and GNU Radio within MacPorts
Alexandru C. already replied about what he has done with regard to your
about gr-osmosdr and rtl-sdr; so, I won’t replicate those. Let me instead
non-MacPorts parts a bit here; this is generic advice regarding developing on
side of Mac OS X.
Yes, his advise helped. I got the gr-osmosdr blocks showing up in gnu
sources group now.
I am still having one final problem, will note it below where you
discuss something that
is probably related.
- I highly recommend you NOT install non-MacPorts files into your MacPorts
prefix (by default, /opt/local). Just good programming practice, and there are
environment variables available for handling this situation.
So in the case of rtl-sdr and gr-osmosdr is it suggested to still use
rtl-sdr but as you say above install non-MacPorts gr-osmosdr in
Or would it be better to be consistent and not install rtl-sdr from
install them both the non-MacPorts way?
Getting the PYTHONPATH correct seems to be what got the blocks showing
in gnuradio-companion, along with the suggestion that Alex also had.
- Mac OS X does not use “ldconfig” or the like. You just use what’s installed
by setting PATH and maybe other environment variables, and they refer to what
each executable and/or library needs internally, which allows the dynamic
library loader to do its thing.
Yes I figured out that that was not supported.
I did wonder though if that last step when I install gnuradio via
MacPorts at the very
end where is scans and resolves something might be an issue. Is there a
way to just
rerun that? Would it help? Sorry I am being abstract on this question,
it takes a long
time to build on my machine so I have not reran it to specifically note
what it was
- I highly recommend NOT using the DYLD_* environment variables as a standard
part of your shell environment. These work well for testing after a project
has been built but before it is installed. But, setting one of them will
invariably end up messing up some executable sooner or later; and, you won’t
have any idea why (or, that’s my experience).
Yes I figured this out the hard way. Some people on the net suggested
but on my system it generally messed up something else until I got rid
of it again.
Other people had the advise you gave above and said DONT DO IT.
I have one remaining issue, when I build the flow graph and then attempt
it I get the following error that feels would would have been an
ldconfig, DYLD*, or
maybe even the scan thing I noted above. See problem loading the dylib
Traceback (most recent call last):
File “/Users/mlk/bin/top_block.py”, line 16, in
line 45, in
from osmosdr_swig import *
line 26, in
_osmosdr_swig = swig_import_helper()
line 22, in swig_import_helper
_mod = imp.load_module(’_osmosdr_swig’, fp, pathname, description)
2): Library not loaded: libgnuradio-osmosdr.0.dylib
Reason: image not found
Seems like I am missing one final detail that glues the proper loading
of the dynamic libraries?
I hope this helps! - MLD