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 <n...@nf6x.net> Web page: http://www.nf6x.net/ GnuPG public key available from my web page. _______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
