I am stuck on this problem for long. So,any help will be appreciated.
I am trying to install GnuRadio on Mac OSX 10.6.1 . I have installed the
prerequisites including wxWidgets and py26-wxpython using MacPorts.
However,
gr-wxgui and grc failed to build. The output lines in ./configure that
correspond to this problem are:
checking for Python wxWidgets wrappers >= 2.8… no
checking for Numeric Python extensions… yes
Not building component gr-wxgui.
Hi Bruh - If you installed py26-wxpython and wxWidgets from MacPorts,
then as of this morning neither allow for ‘universal’ compilation, and
wxWidgets goes so far as to enforce 32-bit only compilation. Chances
are your Mac’s compiler is trying to generate 64-bit code. Hence, the
wxpython wrappers are not being found because what’s installed is for
the incorrect architecture. OSX will not allow you to mix 32-bit and
64-bit code within the same program.
That said, the Wx folks have known that their products are not 64-bit
compatible on OSX for along time. The latest release of wxWidget is
64-bit compatible on OSX, but that still leaves the wxPython 64-bit
OSX interface – which is still in beta.
Putting the pieces together, I think if you reinstall all of the
background dependencies for GNU Radio as ‘universal’ and then the wx
stuff as 32-bit, then compile GNU Radio as 32-bit, then everything
should work. I think others on this list have done that in the past,
maybe even commented as such on this list.
That said, I’ve taken over the Qt 4.6 ports on MacPorts – which can
be 64-bit – and in the next couple of days I’ll be releasing new
ports that should allow for gr-qtgui to be usable on OSX. I’ll email
again once that’s further along. After seeing the difference between
wx and qt, I’d much prefer to use the latter.
Hi Bruh - If you installed py26-wxpython and wxWidgets from MacPorts,
then as of this morning neither allow for ‘universal’ compilation, and
wxWidgets goes so far as to enforce 32-bit only compilation. Chances
are your Mac’s compiler is trying to generate 64-bit code. Hence, the
wxpython wrappers are not being found because what’s installed is for
the incorrect architecture. OSX will not allow you to mix 32-bit and
64-bit code within the same program.
That said, the Wx folks have known that their products are not 64-bit
compatible on OSX for along time. The latest release of wxWidget is
64-bit compatible on OSX, but that still leaves the wxPython 64-bit
OSX interface – which is still in beta.
Putting the pieces together, I think if you reinstall all of the
background dependencies for GNU Radio as ‘universal’ and then the wx
stuff as 32-bit, then compile GNU Radio as 32-bit, then everything
should work. I think others on this list have done that in the past,
maybe even commented as such on this list.
That said, I’ve taken over the Qt 4.6 ports on MacPorts – which can
be 64-bit – and in the next couple of days I’ll be releasing new
ports that should allow for gr-qtgui to be usable on OSX. I’ll email
again once that’s further along. After seeing the difference between
wx and qt, I’d much prefer to use the latter.
That did the trick and I now installed gnuradio including gr-wxgi and
grc using git, but got this warning:
*** Post-Install Message ***
Warning: python could not find the gnuradio module.
Make sure that /usr/local/lib/python2.6/site-packages is in your
PYTHONPATH
Hi Bruh - Glad to hear you’re getting Wx to work for you. We’re
working on getting the Qt GUI working as well. I know that the state
of Wx on MacPorts is “confusing” right now – to me as well. If I
were you, now that you’ve got it working, I’d leave my MacPorts
install alone until the Wx stuff gets worked out; could be a long
time, and it really depends on how quickly the Wx folks get their
32/64 OSX 10.5/10.6 acts together.
So, I could not figure out why this happened. Any suggestions?
Assuming you setup your .bashrc file exactly as found in the
“Additional Login Scripts” section of that page, and MacPorts is fully
installed to use its own ‘python’, then the PYTHONPATH should read
something like:
where the former path is for MacPorts and the latter for GNU Radio.
If all you’re getting is the PYTHONPATH you list, then I would bet you
haven’t selected (in MacPorts) the correct version of python. What
does “which python” return for you? ditto for “ls -l which python” … if either of those shows that the version is “/usr/bin/
python” or the like, then you need to select the MacPorts’ version,
via (assuming you’re using MacPorts’ port “python26” as I do):
$ sudo port install python_select
$ sudo python_select python26
and that should do the trick. No matter how much automation we build
in, someone eventually messes with some part of it to require even
more Hope this help! - MLD
That did the trick and I now installed gnuradio including gr-wxgui and
grc, but got this warning:
*** Post-Install Message ***
Warning: python could not find the gnuradio module.
Make sure that /usr/local/lib/python2.6/site-packages is in your
PYTHONPATH
Hi Bruh - Glad to hear you’re getting Wx to work for you. We’re
working on getting the Qt GUI working as well. I know that the state
of Wx on MacPorts is “confusing” right now – to me as well. If I
were you, now that you’ve got it working, I’d leave my MacPorts
install alone until the Wx stuff gets worked out; could be a long
time, and it really depends on how quickly the Wx folks get their
32/64 OSX 10.5/10.6 acts together.
That is pretty cool. I am very eager for the outcome.
To address your question:
It is kind of confusing. I have Gnuradio installed, so executing the
gnuradio examples in their own directory works fine. But, from the home
directory…it restult in:
$ python dial_tone.py
/opt/local/Library/Frameworks/Python.framework/Versions/2.6/Resources/Python.app/Contents/MacOS/Python:
can’t open file ‘dial_tone.py’: [Errno 2] No such file or directory
Assuming you setup your .bashrc file exactly as found in the
“Additional Login Scripts” section of that page, and MacPorts is fully
installed to use its own ‘python’, then the PYTHONPATH should read
something like:
if either of those shows that the version is “/usr/bin/
python” or the like, then you need to select the MacPorts’ version,
via (assuming you’re using MacPorts’ port “python26” as I do):
$ sudo python_select python26
Selecting version “python26” for python
The macports version is selected but the error remains the same. I am
confused?
Glad to hear you’re getting Wx to work for you. We’re
working on getting the Qt GUI working as well. I know that the state
of Wx on MacPorts is “confusing” right now – to me as well. If I
were you, now that you’ve got it working, I’d leave my MacPorts
install alone until the Wx stuff gets worked out; could be a long
time, and it really depends on how quickly the Wx folks get their
32/64 OSX 10.5/10.6 acts together.
That is pretty cool. I am very eager for the outcome.
To address your question:
It is kind of confusing. I have Gnuradio installed, so executing the
gnuradio examples in their own directory works fine. But, from the home
directory…it restult in:
$ python dial_tone.py
/opt/local/Library/Frameworks/Python.framework/Versions/2.6/Resources/Python.app/Contents/MacOS/Python:
can’t open file ‘dial_tone.py’: [Errno 2] No such file or directory
Assuming you setup your .bashrc file exactly as found in the
“Additional Login Scripts” section of that page, and MacPorts is fully
installed to use its own ‘python’, then the PYTHONPATH should read
something like:
if either of those shows that the version is “/usr/bin/
python” or the like, then you need to select the MacPorts’ version,
via (assuming you’re using MacPorts’ port “python26” as I do):
$ sudo python_select python26
Selecting version “python26” for python
The macports version is selected but the error remains the same. I am
confused?
sudo port selfupdate
sudo port upgrade outdated
sudo port install python_select
sudo python_select python26
sudo port install mesa
sudo port clean --all wxWidgets-python
sudo port -d install py26-wxpython
sudo port install gnuradio
export
PYTHONPATH=/opt/local/lib/python2.6/site-packages:/usr/local/lib/python2.6/site-packages
It is kind of confusing. I have Gnuradio installed, so executing the
gnuradio examples in their own directory works fine. But, from the
home
directory…it restult in:
can’t open file ‘dial_tone.py’: [Errno 2] No such file or directory
Let me see if I understand what you’ve written correctly:
You installed GNU Radio in the standard way: bootstrap, configure,
make, make install. That means the examples ended up at “/usr/local/
share/gnuradio/examples”, and in particular the one you mention at “/
usr/local/share/gnuradio/examples/audio/dial_tone.py”.
“PYTHONPATH=/opt/local/lib/python2.6/site-packages:/usr/local/lib/
python2.6/site-packages” for your shell environment.
When your shell’s directory has been changed “cd /usr/local/share/
gnuradio/examples/audio” and you then do “python dial_tone.py” it
works for you.
When your shell’s directory is it’s “home” (typically on OSX “/Users/
FOO”, where FOO is your username; also called “~”), then issuing the
same command (“python dial_tone.py”) does not work for you because the
script is not found.
All of the above is normal behavior for Linux and pretty much any UNIX
flavor including OSX, and it sounds like GNU Radio is installed
correctly.
The issue is that the script “dial_tone.py” is not in the search path
that Python knows (via the PYTHONPATH & what else is built in to
Python). If you do issue “python -c ‘import sys; print sys.path’”
you’ll see what Python thinks of as its search path. The first entry
is probably ‘’, which corresponds to “.” or the directory from which
Python was called. After that are the directories listed in
PYTHONPATH, and then the rest are those stored in the Python install
at compile-time.
If you want to execute the script you mention from your home
directory, you’ll need to reference it directly, e.g., “python /usr/
local/share/gnuradio/examples/audio/dial_tone.py” should work. Or, if
you want to use that script a lot from other locations, you can always
add its directory to the PYTHONPATH; it’d recommend doing it at the
end, via adding “:/usr/local/share/gnuradio/examples/audio” to what’s
already there.
Also of note: As with Linux and other UNIX flavors, on OSX you
generally don’t actually need the “python” declaration in front of the
file so long as the file is marked executable. As with your example,
if you do “ls -l /usr/local/share/gnuradio/examples/audio/
dial_tone.py” it should come back marked as “x” for everyone (meaning:
executable). Hence you could just do “/usr/local/share/gnuradio/
examples/audio/dial_tone.py” from anywhere, or “cd /usr/local/share/
gnuradio/examples/audio && ./dial_tone.py” and it should function
correctly. Even GUI Python scripts should work correctly without the
“pythonw” in front – though there will be a few stubborn ones that
will complain.
Hope this helps! - MLD
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.
Hope this help! - MLD
This is what I did in OS X 10.6.4: