Re: [Discuss-gnuradio] USRP/gnuradio Issues in OS X

[Mark J. Blair]

On Aug 24, 2010, at 4:58 PM, Michael Dickens wrote:
> Hi Mark - I'm glad you got it working; if you installed all of the background 
> dependencies with MacPorts, compiling GNU Radio should be as simple as:
> 
> [fix bootstrap]
> ./bootstrap
> ./configure

Should be... but isn't.

> with no other options.  IIRC, the 3 primary environment variables you need to 
> have set are PATH (so that /opt/local/bin comes first), PYTHONPATH (so that 
> /opt/local/lib/python2.6/site-packages comes first), and PKG_CONFIG_PATH (so 
> that /opt/local/lib/pkgconfig comes first).  You do not need to set 
> "--with-fusb-tech" at all; it will auto-detect.  You also don't need to set 
> LDFLAGS as you have.  Further, I don't think gr-qtgui is working on OSX just 
> yet, so you really don't need to set CPPFLAGS either.  And, you can have 
> MacPorts select the CC and CXX for you via "gcc_select" -- so those aren't 
> necessary.

The --with-fusb-tech probably isn't necessary for me since I temporarily 
uninstalled libusb-1.0, but with that installed I found it to be necessary to 
specify --with-fusb-tech=libusb1 to get it to work. Anyhting else would cause 
the USRP code to crash when it failed to find the _usb_debug symbol.

I have /opt/local/lib in my path, but I found it necessary to force the 
compilation to use the native compilers in /usr/bin instead in order to find 
the Mac frameworks. I chose to do this with the CC and CXX variables instead of 
gcc_select in this case.

I modified my site.py file so it wouldn't be necessary to add that 
site-packages directory to my PYTHONPATH.

The CPPFLAGS and LDFLAGS variable settings were necessary to get gr-qtgui to 
build, though I don't know if it actually works yet. In particular, some of the 
code included qwt and qwtplot3d headers without specifying their subdirectories 
(i.e., <foo.h> vs. <qwt/foo.h>), so I had to add the -I flags to get them to be 
found. I also had to add that -F flag for the linker to find the QtOpenGL 
framework.

I don't know if there's something screwy about my system configuration, but 
that's what I had to do to get things to build and run.

> My question now is whether or not the other tests you talked about work 
> (e.g., usrp_benchmark_usb.py).  If that works, then you're good to go & can 
> play around with all the other pieces of GNU Radio & USRP.

Ah, good question. I've already been playing with some of the scripts such as 
usrp_fft.pw, usrp_siggen.py and a few others, and with grc, but there have been 
a bunch of pieces that didn't work. I'll try the benchmark script now that I've 
fixed (?) the USB stuff... Success! It consistently gives me one USB under-run 
(I think; it prints "uU") at the beginning, but then runs and declares I can 
get 32MB/sec throughput.

One of the other things that hasn't been working still isn't, but I think it's 
an unrelated error. When I run usrp_am_mw_rcv.py it complains:

RuntimeError: gr_remez: insufficient extremals -- cannot continue


>  But, I'm glad you've gotten this far. - MLD

Thanks! I didn't expect it to be entirely painless (particularly since I'm 
running not-Linux here), and I'll keep plugging along.



-- 
Mark J. Blair, NF6X <address@hidden>
Web page: http://www.nf6x.net/
GnuPG public key available from my web page.