GNU Radio via MacPorts Updated

GNU Radio
1

I’ve updated the GNU Radio install via MacPorts to 3.3.0.

For those OSX users out there who are using GNU Radio and MacPorts,
could you give this a shot & see if it works for you? If you do install
them for testing purposes & want to use a non-MacPorts GIT install for
your actual work, make sure to deactivate / uninstall those from
MacPorts – usually there is no conflict between multiple GNU Radio
installs, but it’s just safer this way.

If you have thoughts or comments on the MacPorts install of GNU Radio on
OSX, I’d love to hear from you. - MLD

Changes

  • I’ve moved “gnuradio-grc” to “gnuradio-companion”, which might cause
    issues since I can’t figure out how to disable the former before
    installing the newer w/o telling the user to explicitly do so & then
    waiting.

  • I’ve deprecated ‘mblock’ and ‘gromnithreads’, which will still install
    but print warnings about their new status (since they do not conflict
    with GNU Radio 3.3).

  • There is a warning when installing ‘pmt’ that it has been integrated
    into ‘gruel’ & to use that port instead; but, the actual ‘pmt’ library
    is installed anyway (since it does not conflict with GNU Radio 3.3).

  • I’ve added ports for ‘atsc’, ‘noaa’, msdd6000’, and ‘qtgui’ – yes,
    with enough external settings Qt / qwt / qwtplot3d can be made to work
    on OSX. I haven’t actually tried this port out to make sure it works
    correctly, but everything passes “make check” so …

2

Hi Michael,

On Sep 7, 2010, at 6:28 PM, Michael D. wrote:

I’ve updated the GNU Radio install via MacPorts to 3.3.0.

I just have a quick question… are all the library dependencies for GNU
Radio build as 32-bit only executables or for both 32-bit and 64-bit?

Best regards,

Elvis D.

3

On Sep 7, 2010, at 2:04 PM, Elvis D. wrote:

Does it use the GTK+ with support for native OS X look and feel?

It uses whatever MacPorts provides; by default:

gtk2 @2.20.1_0 +x11

but I can specify for it to use instead:

gtk2 @2.20.1_0 +no_x11 +quartz

and then I have to go through all of the various graphics ports & make
sure they are also +no_x11+quartz . I haven’t tried this latter to make
sure it works, but I don’t see why it wouldn’t (unless one of the ports
is broken with those variants).

are all the library dependencies for GNU Radio build as 32-bit only executables or for both 32-bit and 64-bit?

I built solely as x86_64 (64-bit), not as universal (which would include
i386 [32-bit]). I haven’t gone through all of the installed libraries
by hand to verify that all are 64-bit, but linking wouldn’t work if they
weren’t so I’m guessing they are. Also, all of the testing I’ve done is
to run “make check” (which does pass) … I haven’t tried a GUI or
anything yet. Hopefully I’ll find time to try it in the next couple of
days; or, maybe some other GNU Radio OSX user will beat me to doing so
:slight_smile:

Good questions; keep 'em coming! - MLD

4

On Tue, Sep 7, 2010 at 4:28 PM, Michael D. [email protected]
wrote:

OSX, I’d love to hear from you. - MLD

Hi Michael,

Thank you for this new update. I have now installed it and it seems to
be
working fine.
Some notes:

(1) I didn’t have macports installed so it was a clean installation.
After
installing the macports app I just ran “sudo port install gnuradio” and
let
it run overnight.

(2) After installation I had to add
export PYTHONPATH=$PYTHONPATH:/opt/local/lib/python2.6/site-packages
to my .profile file. I guess it is normal, but I was a bit surprised
since
macports has already modified this file to set up the PATH and also
other
environment variables like pkg-config seem to be set up correctly.
Anyway,
after doing this I could execute the audio examples :slight_smile:

(3) gnuradio-companion couldn’t find “pygtk” and to make it work I also
had
to add
/opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/
to my PYTHONPATH. So, gnuradio-companion is now working and I could
execute
simple wxgui script with audio, FFT scope and waterfall :slight_smile:

(4) Not sure about the Qt stuff… In the source tree I tried to execute
the
pyqt_example.py script and got:
Traceback (most recent call last):
File “pyqt_example.py”, line 4, in
from gnuradio.qtgui import qtgui
File “/opt/local/lib/python2.6/site-packages/gnuradio/qtgui/qtgui.py”,
line 24, in
_qtgui = swig_import_helper()
File “/opt/local/lib/python2.6/site-packages/gnuradio/qtgui/qtgui.py”,
line 20, in swig_import_helper
_mod = imp.load_module(‘_qtgui’, fp, pathname, description)
ImportError:
dlopen(/opt/local/lib/python2.6/site-packages/gnuradio/qtgui/_qtgui.so,
2):
Library not loaded: libqwtplot3d.0.dylib
Referenced from:
/opt/local/lib/python2.6/site-packages/gnuradio/qtgui/_qtgui.so
Reason: image not found

I found the libqwtplot3d.0.dylib in /opt/local/lib but I get the same
error
even after adding it to LD_LIBRARY_PATH in the .profile file

Next I will try my USRP. On Ubuntu Linux we have to set up udev to
recognize
the USRP, is there something similar that has to be done on the mac?

Cheers
Alex

5

On Thu, Sep 9, 2010 at 11:26 PM, Alexandru C. [email protected]
wrote:

line 20, in swig_import_helper

I learned that on OSX it is dyld and not ld; however, changing it to
DYLD_LIBRARY_PATH gave another error:
Traceback (most recent call last):
File “./pyqt_example.py”, line 4, in
from gnuradio.qtgui import qtgui
File “/opt/local/lib/python2.6/site-packages/gnuradio/qtgui/qtgui.py”,
line 24, in
_qtgui = swig_import_helper()
File “/opt/local/lib/python2.6/site-packages/gnuradio/qtgui/qtgui.py”,
line 20, in swig_import_helper
_mod = imp.load_module(‘_qtgui’, fp, pathname, description)
ImportError:
dlopen(/opt/local/lib/python2.6/site-packages/gnuradio/qtgui/_qtgui.so,
2):
Library not loaded:
/System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libLAPACK.dylib
Referenced from:
/System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/vecLib
Reason: Incompatible library version: vecLib requires version 1.0.0 or
later, but libLAPACK.dylib provides version 0.0.0

I tried to google this and found some forum discussions suggesting that
this
is problem with the port package and that using DYLD_LIBRARY_PATH is not
recommended - instead DYLD_FALLBACK_LIBRARY_PATH can be used. Tried that
and
got a different error:
Traceback (most recent call last):
File “./pyqt_example.py”, line 5, in
from PyQt4 import QtGui, QtCore
ImportError:
dlopen(/opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/PyQt4/QtCore.so,
2): Symbol not found: __PyByteArray_empty_string
Referenced from:
/opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/PyQt4/QtCore.so
Expected in: flat namespace
in
/opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/PyQt4/QtCore.so

Alex

6

Thank you, Alexandru, for the report. I’m glad the basics work for you;
they do for me as well. Everything seems to work except for the QtGUI.
I’ve found in my install that the QtGUI doesn’t work yet either, in
exactly the same way that yours fails. I know where the problem lies,
and I’ll be working on patches & hopefully get them in place tomorrow.
I’ll post another email to the list once it works for me. - MLD

ps1> You shouldn’t set the DYLD_LIBRARY_PATH to find libraries; OSX’s
dyld is smart enough to find them – but only if it knows where to look,
which is the issue in this case (no path, just the library name).

ps2> On OSX, you do not need to set up udevs or anything; the USRP just
works :slight_smile:

7

On Wed, Sep 8, 2010 at 4:27 AM, Michael D. [email protected]
wrote:

and then I have to go through all of the various graphics ports & make sure
they are also +no_x11+quartz . I haven’t tried this latter to make sure it
works, but I don’t see why it wouldn’t (unless one of the ports is broken
with those variants).

I tried on another computer to install gtk2 +no_x11 +quartz and learned
that
pango (the font rendering engine) is quite broken. It’s a known problem:
https://trac.macports.org/ticket/20924
Until fixed it is not very useful because all text is dsplayed as
squares.

Alex

8

guys im having this issue with wxgui when trying to run usrp_fft.py on
snow leopard

$ usrp_fft.py
Traceback (most recent call last):
File “/opt/local/bin/usrp_fft.py”, line 27, in
from gnuradio.wxgui import stdgui2, fftsink2, waterfallsink2,
scopesink2, form, slider
File
“/opt/local/lib/python2.6/site-packages/gnuradio/wxgui/stdgui2.py”, line
24, in
import wx
File
“/var/tmp/wxWidgets/wxWidgets-13~231/2.6/DSTROOT/System/Library/Frameworks/Python.framework/Versions/2.6/Extras/lib/python/wx-2.8-mac-unicode/wx/init.py”,
line 45, in
File
“/var/tmp/wxWidgets/wxWidgets-13~231/2.6/DSTROOT/System/Library/Frameworks/Python.framework/Versions/2.6/Extras/lib/python/wx-2.8-mac-unicode/wx/_core.py”,
line 4, in
ImportError:
/System/Library/Frameworks/Python.framework/Versions/2.6/Extras/lib/python/wx-2.8-mac-unicode/wx/core.so:
no appropriate 64-bit architecture (see “man python” for running in
32-bit mode)

i have tried
defaults write com.apple.versioner.python Prefer-32-Bit -bool yes
and
export VERSIONER_PYTHON_PREFER_32_BIT=yes
but still get the same error
any ideas?

9

Hi,

On Sep 15, 2010, at 12:49 AM, dave k wrote:

ImportError: /System/Library/Frameworks/Python.framework/Versions/2.6/Extras/lib/python/wx-2.8-mac-unicode/wx/core.so: no appropriate 64-bit architecture (see “man python” for running in 32-bit mode)

i have tried
defaults write com.apple.versioner.python Prefer-32-Bit -bool yes
and
export VERSIONER_PYTHON_PREFER_32_BIT=yes
but still get the same error
any ideas?

Just check if wxWidgets/wxPython is working correctly by typing the
following commands:

$ python

import wx
wx.VERSION_STRING
‘2.9.1.0’

exit()
$

Best regards,

Elvis D.

10

Hi Michael,

On Sep 15, 2010, at 1:12 AM, Michael D. wrote:

Hi Dave - We’re just discussing this issue (32-bit execution) on the MacPorts’ lists. The quick end-result is: With the current MacPorts’ provided python2.6 or older, the PREFER_32_BIT stuff does not work because ‘python’ is actually just a wrapper around ‘exec’ and the bit-preferences are no passed through. Apple’s python2.6 -does- work, as does python2.7 and newer, because this command was moved to “posix_spawn”; see < Source Browser > for the source code and changes Apple made (somewhere in there).

I can confirm that apple’s default python-2.6 works in 32-bit mode.

As to your actual error when running “usrp_fft.py”: Apparently WX is not installed as 64-bit. I haven’t gotten this far in my testing (lots on my queue already), but my memory is that this has been an issue for a -long- time & still isn’t resolved. I don’t remember the exact root cause any longer.

For the wxWidgets/wxPython issue, here’s what I’ve found out so far:

a. wxWidgets/wxPython 2.9.2 and higher builds and works under cocoa
64-bits.

I’ve tested the non-OpenGL vesions of the widgets in gr-wxgui, and that
appears to be working.

However, for the OpenGL versions of these widgets, there are some
breaking API changes between wxWidgets 2.8.x and 2.9.x. The changes are
documented in the wxWidgets OpenGL cube example.

b. Robin Dunn provides a synchronized release of his sources for
wxWidgets/wxPython 2.9.x, since we usually have the problem of version
mismatches, and re-swigging. You can find a link to the download in this
discussion thread:

http://groups.google.com/group/wxPython-dev/browse_thread/thread/dd7ff9dfb5d99686?pli=1

c. Under Mac OS X 10.6.4, you already have an installation of wxWidgets
2.8.8.1

$ export VERSIONER_PYTHON_PREFER_32_BIT=yes
$ python
Python 2.6.1 (r261:67515, Feb 11 2010, 00:51:29)
[GCC 4.2.1 (Apple Inc. build 5646)] on darwin
Type “help”, “copyright”, “credits” or “license” for more information.

import wx
wx.VERSION_STRING
‘2.8.8.1’
exit()

At the moment, I’m slowly building all the dependent libraries for i386
and x86_64 architectures, and bring it up to the wxWidgets/wxPython
dependencies. This way, I can simultaneously try a couple of
permutations/combinations with say wxWidgets/wxPython 2.8.x and
Carbon/32-bits and GNU Radio at 32-bits, or if I solve the OpenGL
context issue, wxWidgets/wxPython 2.9.x Cocoa/64-bits and GNU Radio at
64-bits.

Best regards,

Elvis

11

i compiled from scratch wxWidgets 2.9.1, but python is still using mac’s
2.8 version. How do i tell python to use the locally installed version?

12

HI Dave,
Just some info, not directly related but useful to keep
in mind… wxPython and wxWidgets 2.8.1.1 is already installed on Mac OS
X 10.6.4. However, for some reason the GNU Radio configure process is
not able to detect the wxPython installation. But that would be for
32-bit carbon.

On Sep 15, 2010, at 1:41 PM, dave k wrote:

i compiled from scratch wxWidgets 2.9.1, but python is still using mac’s 2.8 version. How do i tell python to use the locally installed version?

For 64-bit cocoa support, you’ll need to install both wxWidgets-2.9.1
and wxPython-2.9.1 from sources, and more specifically from Robin Dunn’s
workspace, since the two are synchronized with each other, and then
update your .profile path.

I’m not using Mac Ports, so you’ll have to point the environment
variables to the Mac Ports installed location, which is in /opt, or to
the wxPython installed location from sources.

Here are the contents of my .profile file.

wxWidgets

export WXWIN=/Users/elvis/Tool/wxWidgets

GNU Radio

export
PATH=/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/X11R6/bin:$PATH
export
PKG_CONFIG_PATH=/usr/local/lib/pkgconfig:/usr/lib/pkgconfig:/usr/X11R6/lib/pkgconfig:$PKG_CONFIG_PATH
export
MANPATH=/usr/local/share/man:/usr/share/man:/usr/X11R6/man:$MANPATH
export INFOPATH=/usr/local/share/info:/usr/share/info:$INFOPATH
export LDFLAGS=

setup PYTHON variables, depending on what’s first in the $path

export PYTHON_VERSION=python -V 2>&1 | sed -e 's@\.@ @2' | awk '{ print $2 }'
export PYTHON_ROOT=which python | sed -e 's@/bin/python@@g'
export
PYTHONPATH=${PYTHON_ROOT}/lib/python${PYTHON_VERSION}/site-packages
if [ ${PYTHON_ROOT} != “/usr/include” ]; then
export
PYTHONPATH=${PYTHONPATH}:/Library/Python/2.6/site-packages:/usr/local/lib/python${PYTHON_VERSION}/site-packages
fi

User entries

export DYLD_LIBRARY_PATH=/usr/local/lib:$DYLD_LIBRARY_PATH

Not sure if this is going to work, but you could give it a shot. I’m
working on this too, at the moment, and should have some results in a
couple of days.

Best regards,

Elvis

13

Hi Dave - We’re just discussing this issue (32-bit execution) on the
MacPorts’ lists. The quick end-result is: With the current MacPorts’
provided python2.6 or older, the PREFER_32_BIT stuff does not work
because ‘python’ is actually just a wrapper around ‘exec’ and the
bit-preferences are no passed through. Apple’s python2.6 -does- work,
as does python2.7 and newer, because this command was moved to
“posix_spawn”; see <
Source Browser > for the
source code and changes Apple made (somewhere in there).

As to your actual error when running “usrp_fft.py”: Apparently WX is not
installed as 64-bit. I haven’t gotten this far in my testing (lots on
my queue already), but my memory is that this has been an issue for a
-long- time & still isn’t resolved. I don’t remember the exact root
cause any longer.

Sorry I can’t be of more help yet; thanks for testing & reporting back.

  • MLD
14

Michael,

Some time back, I was trying to get a 32-bit version of GnuRadio,
including grc, to build and install on OSX 10.6. That project went
on hold for a while, but is now starting to wake back up, so I gave
it another try, using your 3.3.0 macport. Here’s the
results:

OS is 10.6.4, on a 1-year old 17" MackBook Pro
2.8GHz Intel Core 2 Duo with 4GB of ram.
It came with 10.6 installed, and has Xcode installed.

First I upgraded ports with “sudo port selfupdate” .

Next, I removed all installed packages with
“sudo port -f uninstall installed”
and
“sudo port clean --work --archive all”

Next, I edited /opt/local/etc/macports/macports.conf to add
the line “build_arch i386” to make the default
arch 32-bit instead of 64-bit.

Next, I did “sudo port install gnuradio”. This ground away
for a while and failed on Boost. What I found was that the
Boost port seems to be broken when trying to build 32-bit
only. Manually installing Boost by doing
“sudo port clean boost” and
“sudo port install boost +universal”
got both 32-bit and 64-bit versions successfully built.

I then repeated “sudo install gnuradio” and came to the next
similar problem, this time with gcc44. Again, cleaning, building
with +universal and then re-trying to install gnuradio
got past it.

Eventually, after a largish number of these, I was down to
only gnuradio-qtgui not installed. A quick test of
gnuradio-companion brought up it’s gui, and I was able
to construct and save a simple graph.

After more fighting with broken ports, I finally got
gnuradio-qtgui to install. But then when I tried to
run gnuradio-companion, it failed, claiming it could not
find some files.

I (perhaps foolishly) uninstalled gnuradio-companion and
tried to reinstall it. The build now fails! The error from
the build log is:

.
.
.
:info:configure Component gr-wxgui will be included from a pre-installed
library and includes.
:info:configure checking for PyQt4 for Qt4… no
:info:configure Not building component gr-qtgui.
:info:configure Not building component gr-sounder.
:info:configure Not building component gr-utils.
:info:configure Not building component gnuradio-examples.
:info:configure checking for xdg-mime… false
:info:configure checking for Python >= 2.5… yes
:info:configure checking for Python Cheetah templates >= 2.0.0… yes
:info:configure checking for Python lxml wrappers >= 1.3.6… no
:info:configure checking for Python gtk wrappers >= 2.10.0… no
:info:configure configure: error: Component grc has errors; stopping.
.
.
.

Checking my installed ports shows

py26-gtk @2.17.0_1 (active)
py26-wxpython @2.8.10.1_0+gtk (active)
wxWidgets-python @2.8.10.1_1+gtk (active)

After two days, I’m stuck. Any ideas?

@(^.^)@ Ed

Michael D. wrote:

I’ve updated the GNU Radio install via MacPorts to 3.3.0.
For those OSX users out there who are using GNU Radio and MacPorts, could you give this a shot & see if it works for you? If you do install them for testing purposes & want to use a non-MacPorts GIT install for your actual work, make sure to deactivate / uninstall those from MacPorts – usually there is no conflict between multiple GNU Radio installs, but it’s just safer this way.

15

On Sep 14, 2010, at 5:12 PM, Michael D. wrote:

We’re just discussing this issue (32-bit execution) on the MacPorts’ lists. The quick end-result is: With the current MacPorts’ provided python2.6 or older, the PREFER_32_BIT stuff does not work because ‘python’ is actually just a wrapper around ‘exec’ and the bit-preferences are no passed through. Apple’s python2.6 -does- work, as does python2.7 and newer, because this command was moved to “posix_spawn”; see < Source Browser > for the source code and changes Apple made (somewhere in there).

The above is correct as stated. That said, for the continued discussion
on the MP-dev list:

The way around this issue with MacPorts’ Python 2.6 is to specify the
whole path to the executable:

$ arch -i386
/opt/local/Library/Frameworks/Python.framework/Versions/2.6/Resources/Python.app/Contents/MacOS/Python
-c ‘import sys; print(sys.maxsize)’

will print out: 2147483647. While

$ arch -x86_64 …

will print out: 9223372036854775807. Of course, this mean that in order
to execute a python script (e.g., usrp_fft.py), one needs to specify
both the Python with full path as well as the script with full path (or
‘’ or ‘./’ if in the current directory)

$ arch -i386
/opt/local/Library/Frameworks/Python.framework/Versions/2.6/Resources/Python.app/Contents/MacOS/Python
/path/to/usrp_fft.py [options]

We shouldn’t be allows to have this much fun! - MLD

16

Hi Ed - Good stuff; I’m glad someone else is trying these ports out. A
few thoughts:

(1) Can you send me, off list, the issues you’re having getting ports
installed as i386 or universal or whatever (ports & log files as
indicated by port)? I’ll see what I can do to fix them up. For
example, “real soon now” I’ll be checking in py2X-numpy that is truly
+universal, and should allow a host of other py2X ports to work
correctly. I can say that when you have native x86_64, running as i386
is known to have issues with various ports – but some correctly handle
the situation (e.g., qt4-mac will once I’ve updated it to 4.7.0 next
week), but it all really depends on who’s maintaining the port & how
busy s/he is.

(2) Regarding your actual issue:

On Oct 1, 2010, at 2:55 PM, Ed Criscuolo wrote:

:info:configure checking for Python Cheetah templates >= 2.0.0… yes
:info:configure checking for Python lxml wrappers >= 1.3.6… no
:info:configure checking for Python gtk wrappers >= 2.10.0… no
:info:configure configure: error: Component grc has errors; stopping.

Checking my installed ports shows

py26-gtk @2.17.0_1 (active)
py26-wxpython @2.8.10.1_0+gtk (active)
wxWidgets-python @2.8.10.1_1+gtk (active)

The configure code for this is in config/grc_grc.m4:32-36. You can
check manually via:

$ python

import sys
sys.version.split()[0] >= “2.5”
[works]

$ python

import Cheetah
Cheetah.Version >= “2.0.0”
[works]

$ python

import lxml.etree
lxml.etree.LXML_VERSION >= (1, 3, 6, 0)
[fails]

$ python

import gtk
gtk.pygtk_version >= (2, 10, 0)
[fails]

so from the configure script, the first 2 will work while the latter 2
will not. I’m guessing this has something to do with 32/64-bit issues,
that the “import foo” will fail, not the version checking. Please try
the above & let me know what the actual errors are. I’ll then send you
some other commands to further check out your install – I need to get
my install working (again) first, so that I can be of more help :slight_smile: I’m
trying to get the +quartz variant working, since there now seems to be
a fix for the Pango issue everyone has encountered & that will allow for
64-bit GUIs; if I can’t do that in a timely manner, I’ll settle for +gtk
& 32-bit. I’m also trying full +universal, just to be complete.

Thanks again. - MLD

17

On Sep 7, 2010, at 7:28 AM, Michael D. wrote:

I’ve updated the GNU Radio install via MacPorts to 3.3.0.

I’m sorry that I’m so terribly late trying this out, but I got
distracted from working with gnuradio stuff for a while. I finally got
around to trying this tonight, and it seems to be working for me so far.
Hooray! I’ll probably put my efforts at perfecting a build from the git
repository on hold for the time being, since i was mostly doing that to
get around issues I had with the older MacPort version.

Some details:

  • 2.66 GHz Intel Core 2 Duo MacBook Pro w/ 4G RAM, running 10.6.4.

  • All sorts of extra stuff installed under MacPorts previously to get
    the git codebase to build, so I’m not a good test case for dependencies
    on a fresh system.

  • I uninstalled the git codebase with “sudo make uninstall” to get it
    out of the way, then installed gnuradio from MacPorts.

  • usrper, usrp_fft.py, usrp_wfm_rcv.py and gnuradio-companion appear to
    be working correctly.

Thank you very much for updating the MacPorts release, and I’ll speak up
if I find any problems or come up with any suggestion.

Gack, I have about 200 messages to clear out from my discuss-gnuradio
inbox now… :slight_smile:

–
Mark J. Blair, NF6X [email protected]
Web page: http://www.nf6x.net/
GnuPG public key available from my web page.

18

On Fri, Sep 10, 2010 at 2:52 AM, Michael D. [email protected]
wrote:

Thank you, Alexandru, for the report. I’m glad the basics work for you;
they do for me as well. Everything seems to work except for the QtGUI.
I’ve found in my install that the QtGUI doesn’t work yet either, in exactly
the same way that yours fails. I know where the problem lies, and I’ll be
working on patches & hopefully get them in place tomorrow. I’ll post
another email to the list once it works for me. - MLD

Greetings,

I don’t know if anything got fixed in the macports package but I got a
tip
to execute a “python_select python26” and reboot. After doing so and
installing py26-scipy I could execute the qt_digital.py example included
in
the gr-qtgui component (see attached screenshot). I have the latest
macports
packages installed:
qt4-mac 4.7.1 quartz variant
py26-pyqt4 4.8.1 (?)

Alex

19

On Nov 12, 2010, at 4:12 PM, Alexandru C. wrote:

I don’t know if anything got fixed in the macports package but I got a tip to
execute a “python_select python26” and reboot. After doing so and installing
py26-scipy I could execute the qt_digital.py example included in the gr-qtgui
component (see attached screenshot). I have the latest macports packages
installed:
qt4-mac 4.7.1 quartz variant
py26-pyqt4 4.8.1 (?)

I realized after a bit of testing that Qt 4.7.0 removed the CONFIG
option “absolute_library_soname” when compared with Qt 4.6.3 – at least
for macx-g++ varieties – as well as changed some other functionality
internal to QMake. This option sets the “install_name” (self-id) of any
created libraries to include the full path to the library instead of
just the library name. That was the original issue, way back in
September, that was causing so many problems for those using MacPorts to
install GNU Radio and/or its dependencies. If the self-id isn’t correct
and another library links against it, then the new library will contain
the incorrect self-id – thus requiring one to set a library search path
instead of relying on the libraries themselves (which in OSX is just not
the way it is done). So, Qt 4.7.0_1 corrected this and other issues
with the way QMake works, fixing a bunch of little problems along the
way that made us developers’ lives easier. I never got back to testing
the GNU Radio ports to make sure they still work, so I’m glad to hear
that they’re OK. Thanks for the update! - MLD

20

Hey Michael,

I have the grc running with the usrp fm receiver example. Neat. This
is a on a Macbook Pro with a clean macports install. I had to wait a
couple of days for a resolution to a problem with the atlas install but
otherwise it went OK.

So now I’m digging into trying to learn/use this environment. I do see
some problems.

1st off, where is all the source code? I found the include files but no
cpp.

Also there seem to be multiple libraries installed. When I try to run
usrp_tx_rcv.py I see:

napierm-mac:usrp napierm$ ./usrp_tv_rcv.py
objc[548]: Class SDLTranslatorResponder is implemented in both
/opt/local/lib/libSDL-1.2.0.dylib and
/opt/local/lib/libgnuradio-video-sdl-3.3.0.0.dylib. One of the two will
be used. Which one is undefined.
objc[548]: Class SDL_QuartzView is implemented in both
/opt/local/lib/libSDL-1.2.0.dylib and
/opt/local/lib/libgnuradio-video-sdl-3.3.0.0.dylib. One of the two will
be used. Which one is undefined.
objc[548]: Class SDL_QuartzWindowDelegate is implemented in both
/opt/local/lib/libSDL-1.2.0.dylib and
/opt/local/lib/libgnuradio-video-sdl-3.3.0.0.dylib. One of the two will
be used. Which one is undefined.
objc[548]: Class SDL_QuartzWindow is implemented in both
/opt/local/lib/libSDL-1.2.0.dylib and
/opt/local/lib/libgnuradio-video-sdl-3.3.0.0.dylib. One of the two will
be used. Which one is undefined.
Xlib: extension “RANDR” missing on display
“/tmp/launch-HFhC87/org.x:0”.

Do I just delete/rename the older one or will that cause problems for
other applications?

Thank you much,

Mark Napier