discuss-gnuradio
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] Unable to build gr-wxgui on Mac OS X 10.6.1


From: Bruhtesfa Ebrahim
Subject: Re: [Discuss-gnuradio] Unable to build gr-wxgui on Mac OS X 10.6.1
Date: Thu, 15 Jul 2010 13:54:25 +0200

Hi Michael,

> 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:
>
> PYTHONPATH=/opt/local/lib/python2.6/site-packages:/usr/local/lib/
> python2.6/site-packages

Printenv returns exactly this:

$ printenv
PYTHONPATH=/opt/local/lib/python2.6/site-packages:/usr/local/lib/python2.6/site-packages


> What does "which python" return for you?

$ Which python
/opt/local/bin/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 python_select python26
Selecting version "python26" for python

The macports version is selected but the error remains the same. I am
confused?

Thanks.
Bruh





On Thu, Jul 8, 2010 at 5:43 PM, Michael Dickens <address@hidden> wrote:
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.

To address your question:


On Jul 8, 2010, at 3:50 AM, Bruhtesfa Ebrahim wrote:
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
}}}
I used the "~/.bashrc" file suggested at

https://radioware.nd.edu/documentation/install-guides/mac-os-x/preliminaries,
where the PYTHONPATH was set to

/usr/local/lib/python${PYTHON_VERSION}/site-packages.

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:

PYTHONPATH=/opt/local/lib/python2.6/site-packages:/usr/local/lib/python2.6/site-packages

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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]