Hi,
I just built gnuradio-3.3.2 from the master-3.3 branch on Mac OS X
10.6.7, all from sources without using mac ports.
When I run a make check command, I get the following error:
… [generic] [SSE]
. [generic] [SSE]
. [generic] [SSE]
. [generic] [SSE]
. [generic] [SSE]
. [generic] [SSE]
.>>> gr_fir_fff: using SSE
.>>> gr_fir_ccf: using SSE
…F…F…
FAIL: test_all
1 of 1 test failed
make[4]: *** [check-TESTS] Error 1
make[3]: *** [check-am] Error 2
make[2]: *** [check-recursive] Error 1
make[1]: *** [check-recursive] Error 1
make: *** [check-recursive] Error 1
I built an earlier release of gnuradio-3.3, before it was restructured,
and those checks passed ok.
For the current build, I uninstalled the previous gnuradio and ettus-uhd
versions using make uninstall, and then built the lastest
gnuradio.master-3.3 branch. I didn’t attempt to rebuild all the
dependent libraries, and those were built when my OS was at 10.6.4.
So, in terms of recent changes between builds, the OS has been upgraded
to 10.6.7, and I cleaned the previous gnuradio-3.3 and ettus-uhd
installs, and then used a fresh clone of the gnuradio and ettus-uhd to
perform the build.
Elvis D.
Just as a data point for comparison: Using MacPorts for all of the
necessary requirements; and the latest GIT masters of UHD and GNU Radio;
I don’t see those check failures. I still get the “socket connect:
Connection refused” on that test, but that’s expected. - MLD
Hi, Michael,
On May 16, 2011, at 11:28 PM, Michael D. [email protected] wrote:
Just as a data point for comparison: Using MacPorts for all of the necessary
requirements; and the latest GIT masters of UHD and GNU Radio; I don’t see those
check failures. I still get the “socket connect: Connection refused” on that
test, but that’s expected. - MLD
I built the latest gnu radio-3.4.0 and for that, make check passed the
earlier test, but failed at the socket connection test that you
mentioned.
However, when I run grc and run the dial tone example, audio doesn’t
work on OS X with gnu radio 3.4.0. Does it work with Macports?
Elvis D.
It looks like GTK isnt coming up right. And the other errors all stem
from that. Is the X server running?
-Josh
It looks like GTK isnt coming up right. And the other errors all stem
from that. Is the X server running?
Yes. I’m running MacPorts’ XQuartz 2.6.1. Odd, but GRC works using
Apple’s X11.app (XQUartz 2.3.6). And, now, randomly, it works in
XQuartz 2.6.1 as well. Hmmm … well, I guess all’s well that ends
well.
The dial_tone.grc file loads correctly, but when I try to execute it I
get:
Generating: “/tmp/dial_tone.py”
Executing: “/tmp/dial_tone.py”
[Errno 2] No such file or directory
And, if I execute /tmp/dial_tone.py, it runs correctly with audio out
working as expected. So, not sure why GRC isn’t finding that generated
.py script … but, again, it’s sort of working at least. - MLD
On May 16, 2011, at 3:35 PM, Elvis D. wrote:
I built the latest gnu radio-3.4.0 and for that, make check passed the earlier
test, but failed at the socket connection test that you mentioned.
However, when I run grc and run the dial tone example, audio doesn’t work on OS
X with gnu radio 3.4.0. Does it work with Macports?
The basic dial_tone.py example works just fine for me (10.6.7, 64-bit,
MacPorts latest everything else). I cannot get gnuradio-companion to
work right now for some reason – maybe Josh knows why? I did a “make
uninstall” before installing, with the hope of removing any cruft. GRC
was working just a couple weeks ago for me, using the latest GIT master.
bash-3.2.48 #700% gnuradio-companion dial_tone.grc
No protocol specified
No protocol specified
No protocol specified
No protocol specified
/opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/gtk-2.0/gtk/init.py:57:
GtkWarning: could not open display
warnings.warn(str(e), _gtk.Warning)
/usr/local/lib/python2.6/site-packages/gnuradio/grc/gui/Actions.py:30:
GtkWarning: gdk_keymap_get_for_display: assertion GDK_IS_DISPLAY (display)' failed _keymap = gtk.gdk.keymap_get_default() /usr/local/lib/python2.6/site-packages/gnuradio/grc/gui/Colors.py:24: GtkWarning: gdk_screen_get_system_colormap: assertionGDK_IS_SCREEN
(screen)’ failed
_COLORMAP = gtk.gdk.colormap_get_system() #create all of the colors
Traceback (most recent call last):
File “/usr/local/bin/gnuradio-companion”, line 48, in
from gnuradio.grc.python.Platform import Platform
File
“/usr/local/lib/python2.6/site-packages/gnuradio/grc/python/Platform.py”,
line 24, in
from FlowGraph import FlowGraph as _FlowGraph
File
“/usr/local/lib/python2.6/site-packages/gnuradio/grc/python/FlowGraph.py”,
line 22, in
from … gui.FlowGraph import FlowGraph as _GUIFlowGraph
File
“/usr/local/lib/python2.6/site-packages/gnuradio/grc/gui/FlowGraph.py”,
line 22, in
import Colors
File
“/usr/local/lib/python2.6/site-packages/gnuradio/grc/gui/Colors.py”,
line 27, in
HIGHLIGHT_COLOR = get_color(’#00FFFF’)
File
“/usr/local/lib/python2.6/site-packages/gnuradio/grc/gui/Colors.py”,
line 25, in get_color
def get_color(color_code): return _COLORMAP.alloc_color(color_code,
True, True)
AttributeError: ‘NoneType’ object has no attribute ‘alloc_color’
Executing: “/tmp/dial_tone.py”
[Errno 2] No such file or directory
its probably the path to pythonw. I made a change to how grc find the
python path. So now that it uses the full python to python, it just
appends a “w” when using grc w/ wx on a macosx. Which was fine on my
test system but not on yours.
can you confirm:
which python
which pythonw
I think the workaround might be if which python + “w” does not exist,
just call pythonw w/out the full path and hope the user has it in the
path (old behavior).
-Josh
% which python
/opt/local/bin/python
% which pythonw
/opt/local/bin/pythonw
On 05/16/2011 06:49 PM, Michael D. wrote:
% which python
/opt/local/bin/python
% which pythonw
/opt/local/bin/pythonw
Hmm, well maybe my hunch is busted. Can you confirm the problem when you
run it w/
/opt/local/bin/python gnuradio-companion
On May 16, 2011, at 9:52 PM, Josh B. wrote:
Hmm, well maybe my hunch is busted. Can you confirm the problem when you
run it w/
/opt/local/bin/python gnuradio-companion
Changes nothing. GRC works, but still generates that error. - MLD