Gnuradio on osx 10.6.4

Ah; a subtle, but important, difference in phrasing between that needs
to be pointed out for those who might be thinking of doing GTK2+Quartz
on OSX:

(1) On Jul 19, 2010, at 12:57 PM, Elvis D. wrote:

One of the things that the guys working on GTK+ mentioned was that
you should completely uninstall MacPorts …

versus (2) < GTK+ Mac OS X download | SourceForge.net >

If you have MacPorts or Fink installed, you must remove all traces
of them from your environment

  • “Removing all traces from your environment” means configuring your
    terminal shell so that it does not use MacPorts or Fink in any
    capacity. In general, that means removing /opt/local or /sw from all
    environment variables – or, as they recommend, just started from a
    fresh user setup since it won’t reference /opt or /sw .

  • “Completely uninstall MacPorts” mean (effectively) “sudo rm -rf /opt/
    local”, which is a draconian solution just to get gtk2 running under
    quartz. I think most of us OSX developers rely to some degree on
    MacPorts or Fink, so this isn’t a practical solution.


also of note, if you do use MacPorts, you can do “port info gtk2
+quartz +no_x11”:
{{{
gtk2 @2.20.1
Variants: +no_x11, +quartz, universal, x11

Description: This is GTK+ version 2.x. GTK+, which stands for
Gimp
ToolKit, is a library for creating GUIs for the
X Windows
System.
Homepage: http://www.gtk.org/

Build Dependencies: pkgconfig
Library Dependencies: tiff, jasper, atk, pango, gettext
Runtime Dependencies: shared-mime-info
}}}
which certainly implies to me that the MacPorts folks have figured out
a way to get the quartz version working without either of the options
mentioned above. I haven’t tried this variant of GTK2, but it’s good
to know that it’s there & maybe I will try it in the future sometime.

  • MLD

Hi Michael,
I noticed something weird, and was wondering if
you’ve come across this already

when using qt-4.7 cocoa 32-bit only, qwt, qwtplot3d, sip and pyqt4, and
building gnuradio, the linker incorrectly attempts to link to the Carbon
libraries,

h …/…/…/libtool --tag=CXX --mode=link g++ -g -O1
-Wno-strict-aliasing -Wno-parentheses -D_THREAD_SAFE -module
-avoid-version -o _qtgui.la -rpath
/usr/local/lib/python2.6/site-packages/gnuradio/qtgui _qtgui_la-qtgui.lo
-lstdc++ libgnuradio-qtgui.la
libtool: link: g++ -Wl,-undefined -Wl,dynamic_lookup -o .libs/_qtgui.so
-bundle .libs/_qtgui_la-qtgui.o ./.libs/libgnuradio-qtgui.dylib
-L/usr/local/lib -L/Developer/Applications/Qt-4.7/lib
/Users/elvis/Tool/gnuradio/gnuradio-core/src/lib/.libs/libgnuradio-core.dylib
/Users/elvis/Tool/gnuradio/gruel/src/lib/.libs/libgruel.dylib
-lboost_thread /usr/local/lib/libfftw3f.dylib
/usr/local/lib/libgsl.dylib /usr/local/lib/libgslcblas.dylib -lcblas
-lstdc++ -lqwt -lqwtplot3d -lz -lm -Wl,-dylib_file
-Wl,/usr/local/lib/libgnuradio-core-3.4git.0.dylib:/Users/elvis/Tool/gnuradio/gnuradio-core/src/lib/.libs/libgnuradio-core.dylib
-Wl,-dylib_file
-Wl,/usr/local/lib/libgruel-3.4git.0.dylib:/Users/elvis/Tool/gnuradio/gruel/src/lib/.libs/libgruel.dylib
-Wl,-dylib_file
-Wl,/usr/local/lib/libgruel-3.4git.0.dylib:/Users/elvis/Tool/gnuradio/gruel/src/lib/.libs/libgruel.dylib
-framework QtOpenGL -framework QtGui -framework QtCore -framework AppKit
-framework Carbon -framework OpenGL -framework AGL -framework
ApplicationServices

However, prior to the build, gnuradio configure correctly detects qwt
headers

checking /usr/local/include/qwt/qwt.h usability… yes
checking /usr/local/include/qwt/qwt.h presence… yes
checking for /usr/local/include/qwt/qwt.h… yes
checking for main in -lqwt… yes
checking /usr/local/include/qwtplot3d/qwt3d_plot.h usability… yes
checking /usr/local/include/qwtplot3d/qwt3d_plot.h presence… yes
checking for /usr/local/include/qwtplot3d/qwt3d_plot.h… yes
checking for main in -lqwtplot3d-qt4… no
checking for main in -lqwtplot3d… yes

Now, thinking perhaps carbon was needed somehow, I rebuilt qt-4.7, qwt,
qwtplot3d, sip and pyqt4 using carbon 32-bit only, but this time around
it doesn’t detect the qwt headers !!

checking /usr/local/include/qwt/qwt.h usability… no
checking /usr/local/include/qwt/qwt.h presence… no
checking for /usr/local/include/qwt/qwt.h… no
Could not find qwt headers

Best regards,

Elvis D.

Hi Elvis - I’m sorry but I really can’t help without further
config.log / debugging info. And, frankly, I don’t have time to dig
through this issue right now – just too much in my queue already.
I’m happy that someone else is trying to get gr-qtgui working, and I
wish you luck on this endeavor. If you do succeed, I hope you publish
how you did it so that the rest of us OSX users might benefit from you
work. - MLD

Hi,
After doing a little digging around in the gnuradio configured
files, I see references to Carbon in

config.status

S[“QT_LIBS”]=" -F/Developer/Applications/Qt-4.7/lib -framework QtOpenGL
-framework QtGui -framework QtCore -framework AppKit -framework Carbon
-framework OpenGL "
"-framework AGL -framework ApplicationServices
-L/Developer/Applications/Qt-4.7/lib -lz -lm "

etc for S[“QTOPENGL_LIBS”] and S[“QTGUI_LIBS”].

This finds itself eventually in the gr-qtgui makefiles, which is
incorrect behaviour. Is because of QwtPlot3d using legacy Qt3Support,
and somehow the Carbon support is getting pulled in?

QTGUI_LIBS = -F/Developer/Applications/Qt-4.7/lib -framework QtGui
-framework QtCore -framework Carbon -framework AppKit -framework
ApplicationServices -L/Developer/Applications/Qt-4.7/lib -lz -lm

QTOPENGL_LIBS = -F/Developer/Applications/Qt-4.7/lib -framework QtOpenGL
-framework QtGui -framework QtCore -framework AppKit -framework Carbon
-framework OpenGL -framework AGL -framework ApplicationServices
-L/Developer/Applications/Qt-4.7/lib -lz -lm

QT_LIBS = -F/Developer/Applications/Qt-4.7/lib -framework QtOpenGL
-framework QtGui -framework QtCore -framework AppKit -framework Carbon
-framework OpenGL -framework AGL -framework ApplicationServices
-L/Developer/Applications/Qt-4.7/lib -lz -lm

Even though I built Qt for cocoa 32-bit, all of the QtGui.pc,
Qt3Support.pc, QtWebKit.pc and QtOpenGL.pc files have the -framework
Cocoa option

Libs.private: -L/Developer/Applications/Qt-4.7/lib
-F/Developer/Applications/Qt-4.7/lib -framework QtCore
-L/Developer/Applications/Qt-4.7/lib -framework Cocoa -lz -framework
AppKit -lz -lz

The net result is I have qt-4.7 built with Cocoa 32-bit only, but it
doesn’t proceed further because of the fact that in the Makefiles, there
is a reference to -framework Cocoa (?)

Also, if I build Carbon 32-bit only, and try to configure gnuradio, it
doesnt detect the qwt headers for some reason. This is happening on the
gnuradio next branch. Perhaps the gr-qtgui configs have been updated in
the master branch and not on the next branch? I was trying to get this
done on the next branch, since only that branch has support for UHD, and
if I want to use my USRP2 with Mac OS X, I need to use UHD, and try to
play around with gr-qtgui.

Best regards,

Elvis D.

Hi Michael,
No problem, I understand. I’ll keep working on
it. Thanks for the help so far, couldn’t have reached this stage without
your timely advice!! :slight_smile:

On Jul 20, 2010, at 8:28 PM, Michael D. wrote:

Shortest Answer: This list isn’t the correct venue for your issues with Qt and Carbon / Cocoa; the GNU Radio build system is working correctly and as expected under the circumstances. If you have issues with the way Qt build on OSX, please see their forums and possibly issue a ticket there.

FYI, the issue with -framework Carbon being generated into the QtGui.pc
is a real bug. It happens, even if I generate a build with cocoa 32-bit
with no qt3 support.

I’ve posted a note on the Qt forum here, describing the bug.

On Jul 20, 2010, at 3:03 AM, Elvis D. wrote:

After doing a little digging around in the gnuradio configured files, I see references to Carbon in config.status

config.status is generated by configure. The reference to “-framework Carbon” comes from how Qt was installed. If you look at the PKG_CONFIG files for Qt, you’ll find ‘Carbon’ in some of them.

This finds itself eventually in the gr-qtgui makefiles, which is incorrect behaviour. Is because of QwtPlot3d using legacy Qt3Support, and somehow the Carbon support is getting pulled in?

This is normal behavior for autotools & the way GNU Radio’s build system works. All of the required Qt libraries’ CFLAGS & LIBS are concatenated, to form what you found.

What I can do in the meantime to progress the gr-qtgui build is to
manually edit the Qt pkgconfig files and replace the reference to Carbon
with Cocoa.

I’ll post the results back to the list, if I’m successful.

best regards,

Elvis

Shortest Answer: This list isn’t the correct venue for your issues
with Qt and Carbon / Cocoa; the GNU Radio build system is working
correctly and as expected under the circumstances. If you have issues
with the way Qt build on OSX, please see their forums and possibly
issue a ticket there.

On Jul 20, 2010, at 3:03 AM, Elvis D. wrote:

After doing a little digging around in the gnuradio configured
files, I see references to Carbon in config.status

config.status is generated by configure. The reference to “-framework
Carbon” comes from how Qt was installed. If you look at the
PKG_CONFIG files for Qt, you’ll find ‘Carbon’ in some of them.

This finds itself eventually in the gr-qtgui makefiles, which is
incorrect behaviour. Is because of QwtPlot3d using legacy
Qt3Support, and somehow the Carbon support is getting pulled in?

This is normal behavior for autotools & the way GNU Radio’s build
system works. All of the required Qt libraries’ CFLAGS & LIBS are
concatenated, to form what you found.

Hi,
Where can I control linker architecture flags to prevent the
following errors? I’ve built qt, qwt and qwtplot3d for 32-bit mode, and
with cocoa support.

However, at link time, gnuradio is trying to link to x86_64.

A little futher down, it is trying to link to the Carbon framework,
whereas I’ve only built the Cocoa framework.

libtool: link: g++ -dynamiclib -Wl,-undefined -Wl,dynamic_lookup -o
.libs/libgnuradio-qtgui-3.4git.0.dylib .libs/FrequencyDisplayPlot.o
.libs/TimeDomainDisplayPlot.o .libs/WaterfallDisplayPlot.o
.libs/Waterfall3DDisplayPlot.o .libs/waterfallGlobalData.o
.libs/ConstellationDisplayPlot.o .libs/spectrumdisplayform.o
.libs/SpectrumGUIClass.o .libs/spectrumUpdateEvents.o
.libs/plot_waterfall.o .libs/qtgui_sink_c.o .libs/qtgui_sink_f.o
/Users/elvis/Tool/gnuradio/gnuradio-core/src/lib/.libs/libgnuradio-core.dylib
-L/usr/local/lib
/Users/elvis/Tool/gnuradio/gruel/src/lib/.libs/libgruel.dylib
-lboost_thread /usr/local/lib/libfftw3f.dylib
/usr/local/lib/libgsl.dylib /usr/local/lib/libgslcblas.dylib -lcblas
-lstdc++ -lqwt -lqwtplot3d -framework QtOpenGL -framework QtGui
-framework QtCore -framework AppKit -framework Carbon -framework OpenGL
-framework AGL -framework ApplicationServices
-L/Developer/Applications/Qt-4.7/lib -lz -lm
-F/Developer/Applications/Qt-4.7/lib -Wl,-dylib_file
-Wl,/usr/local/lib/libgruel-3.4git.0.dylib:/Users/elvis/Tool/gnuradio/gruel/src/lib/.libs/libgruel.dylib
-framework QtOpenGL -framework QtGui -framework QtCore -framework AppKit
-framework Carbon -framework OpenGL -framework AGL -framework
ApplicationServices -install_name
/usr/local/lib/libgnuradio-qtgui-3.4git.0.dylib -compatibility_version 1
-current_version 1.0 -Wl,-single_module

ld: warning: in /usr/local/lib/libqwt.dylib, file was built for i386
which is not the architecture being linked (x86_64)

/bin/sh …/…/…/libtool --tag=CXX --mode=link g++ -g -O1
-Wno-strict-aliasing -Wno-parentheses -D_THREAD_SAFE -module
-avoid-version -o _qtgui.la -rpath
/usr/local/lib/python2.6/site-packages/gnuradio/qtgui _qtgui_la-qtgui.lo
-lstdc++ libgnuradio-qtgui.la
libtool: link: g++ -Wl,-undefined -Wl,dynamic_lookup -o .libs/_qtgui.so
-bundle .libs/_qtgui_la-qtgui.o ./.libs/libgnuradio-qtgui.dylib
-L/usr/local/lib -L/Developer/Applications/Qt-4.7/lib
/Users/elvis/Tool/gnuradio/gnuradio-core/src/lib/.libs/libgnuradio-core.dylib
/Users/elvis/Tool/gnuradio/gruel/src/lib/.libs/libgruel.dylib
-lboost_thread /usr/local/lib/libfftw3f.dylib
/usr/local/lib/libgsl.dylib /usr/local/lib/libgslcblas.dylib -lcblas
-lstdc++ -lqwt -lqwtplot3d -lz -lm -Wl,-dylib_file
-Wl,/usr/local/lib/libgnuradio-core-3.4git.0.dylib:/Users/elvis/Tool/gnuradio/gnuradio-core/src/lib/.libs/libgnuradio-core.dylib
-Wl,-dylib_file
-Wl,/usr/local/lib/libgruel-3.4git.0.dylib:/Users/elvis/Tool/gnuradio/gruel/src/lib/.libs/libgruel.dylib
-Wl,-dylib_file
-Wl,/usr/local/lib/libgruel-3.4git.0.dylib:/Users/elvis/Tool/gnuradio/gruel/src/lib/.libs/libgruel.dylib
-framework QtOpenGL -framework QtGui -framework QtCore -framework AppKit
-framework Carbon -framework OpenGL -framework AGL -framework
ApplicationServices

ld: framework not found QtOpenGL
collect2: ld returned 1 exit status

Best regards,

Elvis

Hi,
I’ve made some progress with getting 64-bit GNU Radio running
on Mac OS X 10.6.4, with 64-bit Cocoa using wxPython.

All the required components are fully built in 64-bit mode. The only
thing I need to resolve is to get OpenGL to work with wxPython. I’ll
post the instructions once I get OpenGL also working.

Here is a screenshot of the non-openGL version of the FFT window from
the gr-wxgui folder.

On Jul 20, 2010, at 9:11 PM, Elvis D. wrote:

I quickly tried the dial-tone.py test app and it was working, so atleast gnuradio-core is built correctly in 64-mode.

Best regards,

Elvis D.

Nice work!!! Great to see that in a Mac window. Please write a howto or
something at some point–wading through all the posts and exchanges is
not only tedious, but some steps get lost along the way.

BTW, you may be the first to have gotten this far, congrats.

Harley Myler

CONFIDENTIALITY: Any information contained in this e-mail (including
attachments) is the property of The State of Texas and unauthorized
disclosure or use is prohibited. Sending, receiving or forwarding of
confidential, proprietary and privileged information is prohibited under
Lamar Policy. If you received this e-mail in error, please notify the
sender and delete this e-mail from your system.

if isinstance(self._foreground, wx.Color):
AttributeError: ‘module’ object has no attribute ‘Color’

The non-OpenGL version of scopesink appears to be working fine though.

it seems wx uses color with a “u” and the compatibility layer that wraps
colour as color is not present for you. Try changing this to Colour and
if it works send the patch. That should work as a general solution.

-Josh

Hi,
I’ve managed to get OpenGL working at a basic level with
wxPython, in 64-bit mode with Cocoa, with PyOpenGL, and tested them
outside gnuradio to see if full support exists.

I’m just down to one final issue, running some of the tests in
gr-wxgui/src/python, all the OpenGL based *sink_gl.py test applications,
launch, but give a blank screen, almost as if the OpenGL rendering
context wasn’t getting initialized or set properly.

$ python scopesink_gl.py

input rate 1000000.0 v_scale None t_scale 3e-05
Traceback (most recent call last):
File
“/Users/elvis/Tool/gnuradio-next/gr-wxgui/src/python/plotter/plotter_base.py”,
line 187, in _on_paint
for fcn in self._draw_fcns: fcn1
File
“/Users/elvis/Tool/gnuradio-next/gr-wxgui/src/python/plotter/plotter_base.py”,
line 59, in draw
self._draw()
File
“/Users/elvis/Tool/gnuradio-next/gr-wxgui/src/python/plotter/grid_plotter_base.py”,
line 204, in _draw_grid
for tick in self._get_ticks(self.x_min, self.x_max, self.x_step,
self.x_scalar)]
File
“/Users/elvis/Tool/gnuradio-next/gr-wxgui/src/python/plotter/grid_plotter_base.py”,
line 302, in _get_tick_label
return gltext.Text(tick_str, font_size=TICK_TEXT_FONT_SIZE)
File
“/Users/elvis/Tool/gnuradio-next/gr-wxgui/src/python/plotter/gltext.py”,
line 340, in init
self._initText()
File
“/Users/elvis/Tool/gnuradio-next/gr-wxgui/src/python/plotter/gltext.py”,
line 376, in _initText
self._centered)
File
“/Users/elvis/Tool/gnuradio-next/gr-wxgui/src/python/plotter/gltext.py”,
line 73, in init
self.createTexture()
File
“/Users/elvis/Tool/gnuradio-next/gr-wxgui/src/python/plotter/gltext.py”,
line 196, in createTexture
if isinstance(self._foreground, wx.Color):
AttributeError: ‘module’ object has no attribute ‘Color’

The non-OpenGL version of scopesink appears to be working fine though.

This is my first time with GNU Radio, so if anyone has any suggestions
on how I can troubleshoot this, it would be great. If I’ve got this one
fixed, then the whole gnuradio + wxgui installation would be ready for
use.

Best regards,

Elvis D.

Hi Josh,

On Jul 22, 2010, at 12:12 AM, Josh B. wrote:

it seems wx uses color with a “u” and the compatibility layer that wraps colour as color is not present for you. Try changing this to Colour and if it works send the patch. That should work as a general solution.

Yes, I just discovered this.

Here is the patch:

diff --git a/gr-wxgui/src/python/plotter/gltext.py
b/gr-wxgui/src/python/plotter/gltext.py
index 67f62ca…617d123 100644
— a/gr-wxgui/src/python/plotter/gltext.py
+++ b/gr-wxgui/src/python/plotter/gltext.py
@@ -193,7 +193,7 @@ class TextElement(object):
img = wx.ImageFromBitmap(bmp)
alpha = img.GetData()

  •    if isinstance(self._foreground, wx.Color):
    
  •    if isinstance(self._foreground, wx.Colour):
           """
           If we have a static color...
           """
    

Once I changed this to wx.Colour, it didn’t show the previous error. how
ever, now I get something related to the OpenGL rendering context:

$ python scopesink_gl.py

input rate 1000000.0 v_scale None t_scale 3e-05
Traceback (most recent call last):
File
“/Users/elvis/Tool/gnuradio-next/gr-wxgui/src/python/plotter/plotter_base.py”,
line 187, in _on_paint
for fcn in self._draw_fcns: fcn1
File
“/Users/elvis/Tool/gnuradio-next/gr-wxgui/src/python/plotter/plotter_base.py”,
line 59, in draw
self._draw()
File
“/Users/elvis/Tool/gnuradio-next/gr-wxgui/src/python/plotter/grid_plotter_base.py”,
line 248, in _draw_grid
(scaled_tick, self.height-self.padding_bottom),
File
“/Users/elvis/Tool/gnuradio-next/gr-wxgui/src/python/plotter/grid_plotter_base.py”,
line 356, in _draw_grid_line
GL.glVertexPointerf(points)
File “/Library/Python/2.6/site-packages/OpenGL/latebind.py”, line 45,
in call
return self._finalCall( *args, **named )
File “/Library/Python/2.6/site-packages/OpenGL/wrapper.py”, line 532,
in wrapperCall
cArgs,
File
“/Library/Python/2.6/site-packages/OpenGL/arrays/arrayhelpers.py”, line
153, in call
contextdata.setValue( self.constant, pyArgs[self.pointerIndex] )
File “/Library/Python/2.6/site-packages/OpenGL/contextdata.py”, line
57, in setValue
context = getContext( context )
File “/Library/Python/2.6/site-packages/OpenGL/contextdata.py”, line
40, in getContext
“”“Attempt to retrieve context when no valid context”""
OpenGL.error.Error: Attempt to retrieve context when no valid context

Best regards,

Elvis D.