Gnuradio on osx 10.6.4

Ninja · July 18, 2010, 11:40am

Hello all,

apology if these question ever been discussed before, but i am trying
google with no luck.

I am following installing gnuradio on osx from
https://radioware.nd.edu/documentation/install-guides/mac-os-x until
find problem at the time configuring gnuradio.

It seems can’t find Python.h, here’s the output:

…
…
checking for python… /usr/local/bin/python
checking for python version… 2.6
checking for python platform… darwin
checking for python script directory…
${prefix}/lib/python2.6/site-packages
checking for python extension module directory…
${exec_prefix}/lib/python2.6/site-packages
checking for Python include path… /usr/local/include/python2.6
checking Python.h usability… no
checking Python.h presence… no
checking for Python.h… no
configure: error: cannot find usable Python headers
bash-3.2$ ls /usr/local/include/python2.6/
Python-ast.h compile.h iterobject.h py_curses.h
rangeobject.h
Python.h complexobject.h listobject.h pyarena.h setobject.h
abstract.h datetime.h longintrepr.h pyconfig.h sliceobject.h
asdl.h descrobject.h longobject.h pydebug.h stringobject.h
ast.h dictobject.h marshal.h pyerrors.h structmember.h
bitset.h enumobject.h metagrammar.h pyexpat.h structseq.h
boolobject.h errcode.h methodobject.h pyfpe.h symtable.h
bufferobject.h eval.h modsupport.h pygetopt.h sysmodule.h
bytearrayobject.h fileobject.h moduleobject.h pymacconfig.h
timefuncs.h
bytes_methods.h floatobject.h node.h pymactoolbox.h
token.h
bytesobject.h frameobject.h object.h pymath.h traceback.h
cStringIO.h funcobject.h objimpl.h pymem.h tupleobject.h
cellobject.h genobject.h opcode.h pyport.h ucnhash.h
ceval.h graminit.h osdefs.h pystate.h unicodeobject.h
classobject.h grammar.h parsetok.h pystrcmp.h warnings.h
cobject.h import.h patchlevel.h pystrtod.h weakrefobject.h
code.h intobject.h pgen.h pythonrun.h
codecs.h intrcheck.h pgenheaders.h pythread.h

what is the meaning of “configure: error: cannot find usable Python
headers”?the Python.h is there, and I already tried using original
python from apple, python from MacPython, and compile manually but same
result occurred. Above sample was taken from python compiled manually.

please advise.

Ninja · July 18, 2010, 11:44pm

On Jul 18, 2010, at 3:35 AM, Ninja wrote:

manually.
Although you can compile some packages from source and have them work,
you will often be missing patches that provide full functionality. I -
highly- recommend using a package manager such as Fink or MacPorts –
where such patches are already incorporated.

That said, if you look at the ‘config.log’ file & search for
“Python.h” you should find whatever the issue/s is/are. Without
seeing that log, there’s very little any of us can do to be of
assistance – I’ve checked out the configure M4 script (config/
gr_python.m4) and it should work correctly for your setup. - MLD

Ninja · July 19, 2010, 1:34am

Hi Michael,

I checked config.log and found the error around Python.h because fortran
compiler is not exist. So, I installed the fortran compiler for mac osx
from Tools - R for Mac OS X - developer's page - GNU Fortan for Xcode, the error message on config.log
looks different now but still around Python.h usability,

Warning: conftest.f:2: Illegal preprocessor directive

Please find full config.log from http://pastebin.ca/1903253

Is gnuradio required specific fortran compiler to be used?

I check from MacPorts for fortran and found these,

[Downloads/gnuradio-3.2.2] > search fortran
adaptor @12.0 (lang)
Parallel Fortran compiliation system

cfitsio @3.250 (science)
C access to FITS data files with optional Fortran wrappers

fgsl @0.9.3 (math, science)
Fortran interface to the GNU scientific library

fpp @1.1 (devel)
Fortran preprocessor for FORTRAN 77 and Fortran 90 programs

ftidy @7.2 (lang)
Fortran Tidy

g95 @0.92 (lang)
Another GNU Fortran 95 compiler

p5-extutils-f77 @1.16 (perl)
Helper for linking C with Fortran subroutines

pgplot @5.2.2 (graphics, devel)
C/Fortran graphics library

py-f2py @2.43.239_1831 (python)
Fortran to Python Interface Generator

qd @2.3.11 (devel, math)
C++/Fortran-90 double-double and quad-double package

Rasyid

Ninja · July 19, 2010, 7:59am

Hi Michael,
I was wondering if you could help me fix an issue
with libusb not being recognized on Mac OS X 10.6.4.

I downloaded libusb-1.0.8 from the following location:

http://sourceforge.net/projects/libusb/files/libusb-1.0/libusb-1.0.8/libusb-1.0.8.tar.bz2/download

$ cd libusb-1.0.8
$ ./configure
$ make -j 4
$ sudo make install

Installation went fine and the headers are stored in
/usr/local/include/libusb-1.0/libusb.h

However, when I run gnuradio configure, I get the following error:

checking for USB… no
checking for USB… no
checking usb.h usability… no
checking usb.h presence… no
checking for usb.h… no
USRP requires libusb header ‘usb.h’ which was not found or was not
usable. See http://www.libusb.org
Unable to find dependency libusb.

I checked config/usrps_libusb.m4, but I don’t know why it is not
detecting the library, and jumping straight to the end and trying to
look for usb.h

$1 is $req_libusb1:

yes : check libusb-1.0

no : check libusb-0.12

“” : check libusb-0.12

AC_DEFUN([USRP_LIBUSB], [
dnl Use PKGCONFIG to check for packages first, then check to
dnl make sure the USB_* variables work (whether from PKGCONFIG
dnl or overridden by the user)

libusbok=no
have_libusb1=no
LIBUSB_PKG_CONFIG_NAME=‘’
if test x$1 = xyes; then
PKG_CHECK_MODULES(USB, libusb-1.0, [
libusbok=yes
have_libusb1=yes
usb_header=‘libusb-1.0/libusb.h’
usb_lib_func=‘libusb_bulk_transfer’
usb_lib_name=‘usb-1.0’
LIBUSB_PKG_CONFIG_NAME=‘libusb-1.0’
])

<snip…>

if test $libusbok = no; then
  dnl if not, see if the pkgconfig module 'libusb-legacy' is

available
PKG_CHECK_MODULES(USB, [libusb-legacy], [
libusbok=yes
LIBUSB_PKG_CONFIG_NAME=‘libusb-legacy’
], [libusbok=no])
fi
dnl set variables for further testing
usb_header=‘usb.h’
usb_lib_func=‘usb_bulk_write’
usb_lib_name=‘usb’
fi

Best regards,

Elvis

Ninja · July 19, 2010, 4:19am

Hi Rasyid - You have the “classic” problem that’s been around for
years now (you can search the GNU Radio archives for “Python.h” and
get hits back to 2005). The problem is that autoconf generates the
“test for Python.h” using C-code but tries to compile it using a
Fortran compiler; “more recent” versions of autoconf fixed this issue
(I’m using 2.65 and it works quite well; 2.66 is the latest release
but it has some issues so I’d stay away from it for now).

I’d recommend upgrading ‘autoconf’ to a more recent version.
Alternatively you can try the following, which may or not work, from
the top-level GNU Radio directory:

edit the file “config/gr_python.m4”
- search for “AC_CHECK_HEADERS([Python.h]” … there is just one
  instance of it.
- insert as the line before: “AC_LANG_PUSH([C])”
- insert as the line after that phrase ends: “AC_LANG_POP([C])”
- the resulting code section should look like:
  {{{
  CPPFLAGS="$CPPFLAGS $PYTHON_CPPFLAGS"
  C_LANG_PUSH([C])
  AC_CHECK_HEADERS([Python.h], [],
  [AC_MSG_ERROR([cannot find usable Python headers])])
  AC_LANG_POP([C])
  CPPFLAGS="$python_save_CPPFLAGS"
  }}}
- save and exit the editor
run bootstrap again in whatever fashion you do so.
run configure again, and see if that works.

Good luck! - MLD

Ninja · July 19, 2010, 3:47pm

Hi Elvis - Did you try “configure --with-fusb-tech=libusb1”? You have
to specify that you want to use LIBUSB version 1; config/
usrp_libusb.m4 checks to see if you’ve specified this on the CLI & if
not then doesn’t check for this version of LIBUSB.

If you did try that command line, then you’ll need to track down where
the PKG_CONFIG file was installed and under what name. Default is
into “${prefix}/lib/pkgconfig”, with ${prefix} being “/usr/local”, and
“libusb-1.0.pc”. Assuming that your shell’s PKG_CONFIG_PATH variable
is set with the default path, then you’ll need to make sure the PC
file name is correct. I’ve only installed LIBUSB (legacy or 1.0) from
MacPorts, so I have no idea if it tweaks the install names.

Good luck! - MLD

Ninja · July 19, 2010, 6:31pm

Hi,
I’ve got Qt-4.7 installed, and the paths set in my .profile.
I’ve also run and tested PyQt4 and it works with the Qt-4.7
installation.

When I run gnuradio configure, I get the following message:

checking for PyQt4 for Qt4… yes
checking for QTCORE… no
gr-qtgui requires libQtCore >= 4.2.
checking for QTGUI… no
gr-qtgui requires libQtGui >= 4.2.
checking for QTOPENGL… no
gr-qtgui requires libQtOpenGL >- 4.2.

These libraries are available on my system, e.g. libQtCore.dylib, etc

What can I do to make it accept the built libraries?

Best regards,

Elvis D.

Ninja · July 20, 2010, 10:32am

Hi Michael,

On Jul 19, 2010, at 6:51 PM, Michael D. wrote:

That flag is for GNU Radio’s ‘configure’ script, and it should work for you given where the PC file was installed.

Thanks, that worked now.

checking for USB… yes
checking libusb-1.0/libusb.h usability… yes
checking libusb-1.0/libusb.h presence… yes
checking for libusb-1.0/libusb.h… yes
checking for libusb_bulk_transfer in -lusb-1.0… yes

Best regards,

Elvis D.

Ninja · July 19, 2010, 4:39pm

Hi Michael,

On Jul 19, 2010, at 5:45 PM, Michael D. wrote:

Hi Elvis - Did you try “configure --with-fusb-tech=libusb1”? You have to specify that you want to use LIBUSB version 1; config/usrp_libusb.m4 checks to see if you’ve specified this on the CLI & if not then doesn’t check for this version of LIBUSB.

I downloaded libusb-1.0.8 from http://www.libusb.org/

and it doesn’t recognize the --with-fusb-tech=libusb1 configure option

$ ./configure --with-fusb-tech=libusb1
configure: WARNING: unrecognized options: --with-fusb-tech

I also checked the older legacy libusb-0.1.12, and that also didn’t have
the --with-fusb-tech=libusb1 option, if you list it with ./configure
–help,
however, the legacy version accepts this as a parameter and for this
warning are being treated as errors and it fails compilation:

gcc -DHAVE_CONFIG_H -I. -Werror -no-cpp-precomp -g -O2 -g -Wall -MT
descriptors.lo -MD -MP -MF .deps/descriptors.Tpo -c descriptors.c -o
descriptors.o >/dev/null 2>&1
cc1: warnings being treated as errors
darwin.c: In function ‘usb_get_next_device’:
darwin.c:257: warning: passing argument 5 of
‘IOCreatePlugInInterfaceForService’ from incompatible pointer type
darwin.c: In function ‘claim_interface’:
darwin.c:560: warning: passing argument 5 of
‘IOCreatePlugInInterfaceForService’ from incompatible pointer type
darwin.c: In function ‘rw_completed’:
darwin.c:772: warning: cast from pointer to integer of different size
darwin.c:772: warning: format ‘%lu’ expects type ‘long unsigned int’,
but argument 4 has type ‘unsigned int’
darwin.c:774: warning: cast from pointer to integer of different size
darwin.c: In function ‘usb_os_find_devices’:
darwin.c:1067: warning: format ‘%08lx’ expects type ‘long unsigned int’,
but argument 3 has type ‘UInt32’
darwin.c:1095: warning: format ‘%08lx’ expects type ‘long unsigned int’,
but argument 5 has type ‘UInt32’
make[2]: *** [darwin.lo] Error 1
make[2]: *** Waiting for unfinished jobs…
g++ -DHAVE_CONFIG_H -I. -g -O2 -MT usbpp.lo -MD -MP -MF .deps/usbpp.Tpo
-c usbpp.cpp -o usbpp.o >/dev/null 2>&1
make[1]: *** [all-recursive] Error 1
make: *** [all] Error 2

Best regards,

Elvis

Ninja · July 20, 2010, 12:34pm

Hi,

On Jul 19, 2010, at 9:23 PM, Elvis D. wrote:

I updated my .profile accordingly

export PKG_CONFIG_PATH=/Developer/Applications/Qt-4.7/lib:$PKG_CONFIG_PATH

I had to explicitly put the full path, and it worked, thanks, Michael

export
PKG_CONFIG_PATH=/Developer/Applications/Qt-4.7/lib/pkgconfig:$PKG_CONFIG_PATH

checking for PyQt4 for Qt4… yes
checking for QTCORE… yes
checking for QTGUI… yes
checking for QTOPENGL… yes
checking qwt/qwt.h usability… yes
checking qwt/qwt.h presence… yes
checking for qwt/qwt.h… yes
checking for main in -lqwt… yes
checking qwtplot3d/qwt3d_plot.h usability… no
checking qwtplot3d/qwt3d_plot.h presence… no
checking for qwtplot3d/qwt3d_plot.h… no
checking qwtplot3d-qt4/qwt3d_plot.h usability… no
checking qwtplot3d-qt4/qwt3d_plot.h presence… no
checking for qwtplot3d-qt4/qwt3d_plot.h… no
Could not find qwtplot3d headers
Not building component gr-qtgui.

Now onto the remaining components …

I think using Python and Qt is really a good way to build these user
interfaces. It might be worth getting up and running, plus porting GRC
to support gr-qtgui.

Best regards,

Elvis

Ninja · July 20, 2010, 1:36pm

Hi Michael,
I’ve managed to get gr-qtgui to pass all
configuration checks for building on Mac OS X 10.6.4.

What do you think I should do next ? Is there a simple gnuradio example
that I can run to test if the gr-qtgui component is working?

For the qwt3dplot-0.2.7 sources, use the attached qmake pro file, to
install it to /usr/local folder. The default pro file doesn’t have the
installation directives.

Here is the result of gnuradio ./configure.

…

checking for PyQt4 for Qt4… yes
checking for QTCORE… yes
checking for QTGUI… yes
checking for QTOPENGL… yes
checking qwt/qwt.h usability… yes
checking qwt/qwt.h presence… yes
checking for qwt/qwt.h… yes
checking for main in -lqwt… yes
checking qwtplot3d/qwt3d_plot.h usability… yes
checking qwtplot3d/qwt3d_plot.h presence… yes
checking for qwtplot3d/qwt3d_plot.h… yes
checking for main in -lqwtplot3d-qt4… no
checking for main in -lqwtplot3d… yes
Component gr-qtgui passed configuration checks; building.

…

The following GNU Radio components have been successfully configured:

config
gruel
gnuradio-core
gr-msdd6000
gr-audio-osx
gr-atsc
gr-cvsd-vocoder
gr-gsm-fr-vocoder
gr-noaa
gr-pager
gr-radio-astronomy
gr-trellis
gr-video-sdl
gr-wxgui
gr-qtgui
gnuradio-examples
docs

Best regards,

Elvis D.

Ninja · July 20, 2010, 12:29pm

Hi,

On Jul 19, 2010, at 8:59 PM, Michael D. wrote:

Hi Elvis - GNU Radio’s configure script is looking for the PKG_CONFIG installed files for QtCore.pc & so forth. Those need to be in the PKG_CONFIG_PATH, and I’d bet that they’re not right now otherwise they would have been found.

I can see a QtCore.pc file in my installation directory

/Developer/Applications/Qt-4.7/lib/pkgconfig/QtCore.pc

I updated my .profile accordingly

export
PKG_CONFIG_PATH=/Developer/Applications/Qt-4.7/lib:$PKG_CONFIG_PATH

Looking at grc_gr_qtgui.m4, I see the following entry

PYTHON_CHECK_MODULE([PyQt4.QtCore], [PyQt4 for Qt4], \

[passed=yes], [passed=no],
[PyQt4.QtCore.PYQT_VERSION >= 260000])

I tested the PyQt4 installation, just to see if it is working, and the
installation is correct, but something in the gnuradio scripts is
preventing it from being recognized

$ python

import sys
from PyQt4.QtGui import *
app = QApplication(sys.argv)
button = QPushButton(“Hello World”, None)
button.show()
app.exec_()

from PyQt4 import QtCore
s = QtCore.QString()
s = “Hello World”
print s
Hello World

Best regards,

Elvis

Ninja · July 20, 2010, 1:51pm

On 19 July 2010 20:31, Elvis D. [email protected] wrote:

Hi Michael,
I’ve managed to get gr-qtgui to pass all
configuration checks for building on Mac OS X 10.6.4.
What do you think I should do next ? Is there a simple gnuradio example that
I can run to test if the gr-qtgui component is working?

Hi Elvis,

You’ll find some examples in the source tree under gr-qtgui/src/python/
I don’t think they are installed in the installation directory.

May I ask, Is this build you just finished completely without using
macports?

Alex

Ninja · July 20, 2010, 2:01pm

Hi Alex,

On Jul 19, 2010, at 10:47 PM, Alexandru C. wrote:

You’ll find some examples in the source tree under gr-qtgui/src/python/
I don’t think they are installed in the installation directory.

I haven’t been able to build it yet, just processing and building all
the required packages one by one.

I now have some build error with gnuradio, relating to the fact that I
am using newer versions of autoconf and libtool, that cause the build
process to fail

May I ask, Is this build you just finished completely without using macports?

Yes, completely without using macports.

The interesting thing is that the latest version of GTK+ supports a
native Mac look and feel. Also PyQt4 works very nicely. This opens up
the possibility of having a native look and feel for GNU Radio under Mac
OS X.

One of the things that the guys working on GTK+ mentioned was that you
should completely uninstall MacPorts, to do the GTK+ installation. The
GTK+ installation has a whole bunch of dependencies, so I will try that
last. That part I think is only related to GRC.

Best regards,

Elvis

Ninja · July 20, 2010, 2:12pm

Hi,
Would someone happen to know the procedure to update gnuradio to
use newer versions of autoconf-2.66 (perhaps I can revert this to 2.65,
since Michael mentioned that 2.66 had issues) and libtool-2.2.10.

I’ve got 2 Mac OS X 10.6.4 installations, one with Mac ports installed
and the other, which I am building completely from the sources. The mac
ports version uses autoconf-2.65 and libtool-2.2.10, so I would like to
update gnuradio to also work with those versions.

Here is the build error that I’m getting right now:

$ make
cd . && /bin/sh /Users/elvis/Tool/gnuradio/missing --run autoheader
aclocal.m4:17: error: this file was generated for autoconf 2.61.
You have another version of autoconf. If you want to use that,
you should regenerate the build system entirely.
aclocal.m4:17: the top level
autom4te: /usr/bin/m4 failed with exit status: 63
autoheader: ‘/usr/local/bin/autom4te’ failed with exit status: 63
WARNING: autoheader' is probably too old. You should only need it if you modifiedacconfig.h’ or configure.ac'. You might want to install theAutoconf’ and GNU m4' packages. Grab them from any GNU archive site. rm -f stamp-h1 touch config.h.in cd . && /bin/sh ./config.status config.h config.status: creating config.h config.status: config.h is unchanged make all-recursive Making all in config make[2]: Nothing to be done forall’.
Making all in gruel
Making all in src
Making all in lib
Making all in pmt
PYTHONPATH=…/…/…/…/gruel/src/lib/pmt srcdir=. /usr/bin/python
./generate_unv.py
GUILE_LOAD_PATH="/Users/elvis/Tool/gnuradio/gruel/src/scheme"
/usr/local/bin/guile -e main -s
./…/…/scheme/gnuradio/gen-serial-tags.scm
./…/…/scheme/gnuradio/pmt-serial-tags.scm
/Users/elvis/Tool/gnuradio/gruel/src/include/gruel/pmt_serial_tags.h
make all-am
/bin/sh …/…/…/…/libtool --tag=CXX --mode=compile g++
-DHAVE_CONFIG_H -I. -I…/…/…/… -I/usr/local/include
-I/usr/local/include -I/Users/elvis/Tool/gnuradio/gruel/src/include
-I/Users/elvis/Tool/gnuradio/gruel/src/include -g -O2 -Wall
-Woverloaded-virtual -D_THREAD_SAFE -MT pmt.lo -MD -MP -MF
.deps/pmt.Tpo -c -o pmt.lo pmt.cc
libtool: Version mismatch error. This is libtool 2.2.10, but the
libtool: definition of this LT_INIT comes from libtool 2.2.4.
libtool: You should recreate aclocal.m4 with macros from libtool 2.2.10
libtool: and run autoconf again.
make[6]: *** [pmt.lo] Error 63
make[5]: *** [all] Error 2
make[4]: *** [all-recursive] Error 1
make[3]: *** [all-recursive] Error 1
make[2]: *** [all-recursive] Error 1
make[1]: *** [all-recursive] Error 1
make: *** [all] Error 2

Best regards,

Elvis D.

Ninja · July 20, 2010, 3:05pm

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, to do the GTK+
installation. The GTK+ installation has a whole bunch of
dependencies, so I will try that last. That part I think is only
related to GRC.

Is their mentioning somewhere on a Wiki or whatever online? Or was
this a private email? I’m a MacPorts developer, and I’d like to know
the reasoning so that I can either quit doing MacPorts or augment it
so-as to overcome whatever deficiency they have found. If it’s just a
matter of selecting configure options or patching code, MacPorts can
handle whatever workaround is necessary. If it’s a matter of personal
opinion, well, that’s OK too – we’re each entitled to what we want to
think and use. - MLD

Ninja · July 20, 2010, 3:06pm

Use the provided ‘bootstrap’ routine, but remember to change the
‘libtoolize’ call to ‘glibtoolize’ or whatever you named that function
on the version you installed yourself. If you used MacPorts to
install GNU Libtool (of which ‘libtoolize’ is a part), then it
prepended the ‘g’ for you.

Ninja · July 20, 2010, 3:09pm

Hi Michael,

On Jul 19, 2010, at 11:55 PM, Michael D. wrote:

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, to do the GTK+ installation. The GTK+ installation has a whole bunch of dependencies, so I will try that last. That part I think is only related to GRC.

Is their mentioning somewhere on a Wiki or whatever online? Or was this a private email? I’m a MacPorts developer, and I’d like to know the reasoning so that I can either quit doing MacPorts or augment it so-as to overcome whatever deficiency they have found. If it’s just a matter of selecting configure options or patching code, MacPorts can handle whatever workaround is necessary. If it’s a matter of personal opinion, well, that’s OK too – we’re each entitled to what we want to think and use. - MLD

It’s mentioned in the following wiki link:

See the pre-requisites section, highlighted

If you have MacPorts or Fink installed, you must remove all traces of
them from your environment before you try to run jhbuild. The easiest
way is to create a new user and run jhbuild while logged in as that
user. Mixing Fink/MacPorts and GTK-OSX will fail.

Best regards,

Elvis

Ninja · July 20, 2010, 3:29pm

Hi,

On Jul 19, 2010, at 11:48 PM, Michael D. wrote:

Use the provided ‘bootstrap’ routine, but remember to change the ‘libtoolize’ call to ‘glibtoolize’ or whatever you named that function on the version you installed yourself. If you used MacPorts to install GNU Libtool (of which ‘libtoolize’ is a part), then it prepended the ‘g’ for you.

I downloaded and installed GNU M4, and switched to autoconf-2.65

running the ./bootstrap routine worked, and now ./configure is build
fine.

Best regards,

Elvis

Ninja · July 20, 2010, 4:55pm

On Jul 20, 2010, at 12:56 AM, Michael D. wrote:

You’re right, of course I didn’t think of that!