Re: [Discuss-gnuradio] GNU Radio release 3.6.3 available for download

[Michael L Kornegay]

> Hi Michael - I'm glad you're having success with at least the MacPorts part 
> of things; 
> and, thanks! I'm glad to be back on top of UHD and GNU Radio within MacPorts 
> again.  

> Alexandru Csete already replied about what he has done with regard to your 
> questions 
> about gr-osmosdr and rtl-sdr; so, I won't replicate those.  Let me instead 
> discuss the 
> non-MacPorts parts a bit here; this is generic advice regarding developing on 
> the UNIX-y 
> side of Mac OS X.

Yes, his advise helped.  I got the gr-osmosdr blocks showing up in gnu 
radio-companion
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 the 
MacPorts
rtl-sdr but as you say above install non-MacPorts gr-osmosdr in /usr/local?  

Or would it be better to be consistent and not install rtl-sdr from MacPorts 
and 
install them both the non-MacPorts way?  

> 
> * I highly recommend installing non-MacPorts files into /usr/local when doing 
> so by hand.  That's generally the purpose of this directory on Mac OS X -- 
> extra non-system stuff.  But, really, you can use pretty much any directory 
> that is non-system, and then set environment variables to access everything.
> 
> * For Python, you can use the PYTHONPATH environment variable to tell it 
> where 
> to look for installed scripts.  For example, if you have scripts installed 
> into 
> /usr/local/lib/python2.7/site-packages, you could tell Python to look there 
> via 
> executing the following in your shell (e.g., adding it to your ~/.bashrc 
> file):
> 
>   export PYTHONPATH=/usr/local/lib/python2.7/site-packages:${PYTHONPATH}

Getting the PYTHONPATH correct seems to be what got the blocks showing up
in gnuradio-companion, along with the suggestion that Alex also had.  

> 
> * To find executables, you set the PATH variable to include the directory/ies 
> you want.  PATH is often already pre-set with the usual places, so you'll 
> want 
> to add to it:
> 
>   export PATH=${PATH}:/usr/local/bin:/usr/local/sbin
> 
> * Each executable can have its own set of environment variables to allow 
> access 
> to specific external files.  You need to check it's source code or manpages 
> or 
> help files for specifics.
> 
> * 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 
scanning.  

> 
> * 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 doing 
this
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 to 
execute
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 below:  


Generating: "/Users/mlk/bin/top_block.py"

Executing: "/Users/mlk/bin/top_block.py"

Traceback (most recent call last):
  File "/Users/mlk/bin/top_block.py", line 16, in <module>
    import osmosdr
  File "/opt/local/lib/python2.7/site-packages/osmosdr/__init__.py", line 45, 
in <module>
    from osmosdr_swig import *
  File "/opt/local/lib/python2.7/site-packages/osmosdr/osmosdr_swig.py", line 
26, in <module>
    _osmosdr_swig = swig_import_helper()
  File "/opt/local/lib/python2.7/site-packages/osmosdr/osmosdr_swig.py", line 
22, in swig_import_helper
    _mod = imp.load_module('_osmosdr_swig', fp, pathname, description)
ImportError: 
dlopen(/opt/local/lib/python2.7/site-packages/osmosdr/_osmosdr_swig.so, 2): 
Library not loaded: libgnuradio-osmosdr.0.dylib
  Referenced from: 
/opt/local/lib/python2.7/site-packages/osmosdr/_osmosdr_swig.so
  Reason: image not found


Seems like I am missing one final detail that glues the proper loading of the 
dynamic libraries?  

Also note:  

PATH=/opt/local/bin:/opt/local/sbin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/usr/X11/bin:/usr/local/MacGPG2/bin:/opt/local/bin:/usr/local/git/bin:/usr/X11/bin
PYTHONPATH=/Users/mlk/bin:/opt/local/lib/python2.7/site-packages:/opt/local/Library/Frameworks/Python.framework/Versions/2.7:


> 
> I hope this helps! - MLD

Thanks,
mlk