Building on 64-bit Linux

GNU Radio
1

Is there a solution for building gnuradio on 64-bit Linux using the
stable v3.4.2 release?

I’m seeing errors similar to the following thread when building gnuradio
from the v3.4.2 source tarball on RHEL 5.7 x86_64:
Re: [Discuss-gnuradio] Compiling gnuradio fails on 64-bit system.

I followed the procedure for cmake
(http://gnuradio.org/redmine/projects/gnuradio/wiki/CMakeWork) and
encountered new errors:

$ cmake -DPYTHON_EXECUTABLE=/usr/bin/python26
-DBOOST_INCLUDEDIR=/usr/include/boost141
-DBOOST_LIBRARYDIR=/usr/lib64/boost141
-DSWIG_EXECUTABLE=/usr/share/swig/2.0.4/bin/swig …/

– Configuring done

– Generating done

– Build files have been written to:
/home/gr/source/git/gnuradio/build

$ make

[ 47%] Generating general_swig_doc.i Error in xml in file /home/gr/source/git/gnuradio/build/gnuradio-core/src/lib/swig/general_swig_doc_swig_docs/xml/gr__simple__framer__sync_8h.xml Traceback (most recent call last): File "/home/gr/source/git/gnuradio/docs/doxygen/swig_doc.py", line 253, in make_swig_interface_file(di, swigdocfilename, custom_output=custom_output) File "/home/gr/source/git/gnuradio/docs/doxygen/swig_doc.py", line 196, in make_swig_interface_file blocks = di.in_category(Block) File "/home/gr/source/git/gnuradio/docs/doxygen/doxyxml/base.py", line 140, in in_category self.confirm_no_error() File "/home/gr/source/git/gnuradio/docs/doxygen/doxyxml/base.py", line 206, in confirm_no_error self.check_parsed() File "/home/gr/source/git/gnuradio/docs/doxygen/doxyxml/base.py", line 203, in check_parsed self._parse() File "/home/gr/source/git/gnuradio/docs/doxygen/doxyxml/doxyindex.py", line 51, in _parse self._members += converted.members() File "/home/gr/source/git/gnuradio/docs/doxygen/doxyxml/base.py", line 174, in members self.confirm_no_error() File "/home/gr/source/git/gnuradio/docs/doxygen/doxyxml/base.py", line 206, in confirm_no_error self.check_parsed() File "/home/gr/source/git/gnuradio/docs/doxygen/doxyxml/base.py", line 203, in check_parsed self._parse() File "/home/gr/source/git/gnuradio/docs/doxygen/doxyxml/doxyindex.py", line 163, in _parse self.set_descriptions(self._retrieved_data.compounddef) AttributeError: 'NoneType' object has no attribute 'compounddef' make[2]: *** [gnuradio-core/src/lib/swig/general_swig_doc.i] Error 1 make[1]: *** [gnuradio-core/src/lib/swig/CMakeFiles/_gnuradio_core_filter.dir/all] Error 2 make: *** [all] Error 2

If it’s hopeless to build from the stable release, what’s the best path
to a working gnuradio installation at the moment?
Thanks!Justin

2

File “/home/gr/source/git/gnuradio/docs/doxygen/doxyxml/base.py”, line 206, in
confirm_no_error
self._parse()
File “/home/gr/source/git/gnuradio/docs/doxygen/doxyxml/doxyindex.py”, line
163, in _parse
self.set_descriptions(self._retrieved_data.compounddef)
AttributeError: ‘NoneType’ object has no attribute ‘compounddef’
make[2]: *** [gnuradio-core/src/lib/swig/general_swig_doc.i] Error 1
make[1]: ***
[gnuradio-core/src/lib/swig/CMakeFiles/_gnuradio_core_filter.dir/all] Error 2
make: *** [all] Error 2

Tom/Ben,

I think doxyindex.py may be relying on an xml field that older doxygen’s
do not define.

Perhaps we could put a big try/catch around this in case it fails and
print to stderr. That way the build keeps going, and its just a warning
printed out in the terminal.

-josh

3

On Tue, Dec 6, 2011 at 5:51 PM, Josh B. [email protected] wrote:

File “/home/gr/source/git/gnuradio/docs/doxygen/swig_doc.py”, line
self._parse()
203, in check_parsed

-josh

Version info, please?

Tom

4

On 12/06/2011 02:56 PM, Tom R. wrote:

make_swig_interface_file(di, swigdocfilename,

File “/home/gr/source/git/gnuradio/docs/doxygen/doxyxml/base.py”, line
self.check_parsed()
2
printed out in the terminal.

-josh

Version info, please?

Tom

Also please attach the gr__simple__framer__sync_8h.xml

-josh

5

On Tue, Dec 6, 2011 at 3:51 PM, Josh B. [email protected] wrote:

self.confirm_no_error()
File “/home/gr/source/git/gnuradio/docs/doxygen/doxyxml/base.py”, line 203, in
check_parsed

I think doxyindex.py may be relying on an xml field that older doxygen’s
do not define.

Perhaps we could put a big try/catch around this in case it fails and
print to stderr. That way the build keeps going, and its just a warning
printed out in the terminal.

-josh

You’re right, it clearly needs to be more robust. I’ll have a look
tonight.

Ben

6

Perhaps we could put a big try/catch around this in case it fails and
print to stderr. That way the build keeps going, and its just a warning
printed out in the terminal.

-josh

You’re right, it clearly needs to be more robust. I’ll have a look tonight.

Ben

I’ve built successfully on the latest master branch so this appears
fixed as of (or sooner):

$ git status

On branch master

nothing to commit (working directory clean)
[jrford@dodeca gnuradio]$ git show
commit fc6151d4516ee86b697602014b83fb08a88c30f0
Merge: 89f934b fa161e1
Author: Tom R. [email protected]
Date: Sun Dec 11 23:01:34 2011 -0500

Merge remote-tracking branch ‘jblum/cmake_qtgui_fix’

Thanks!
Justin

7

On Tue, Dec 6, 2011 at 5:35 PM, Justin F. [email protected]
wrote:

encountered new errors:

– Generating done

– Build files have been written to:
/home/gr/source/git/gnuradio/build

$ make

I’m confused how you are using cmake with the 3.4.2 tarball. That wasn’t
introduced until 3.5. And that swig-doc stuff was just put in yesterday.

Just checking to make sure there’s no confusion about something here.

Tom

8

On Wed, Dec 7, 2011 at 1:06 PM, Ben R. [email protected] wrote:

custom_output=custom_output)
line 203, in check_parsed

self.check_parsed()

[gnuradio-core/src/lib/swig/CMakeFiles/_gnuradio_core_filter.dir/all] Error

print to stderr. That way the build keeps going, and its just a warning
printed out in the terminal.

-josh

You’re right, it clearly needs to be more robust. I’ll have a look
tonight.

Ben

It turns out that the problem was with the ‘&’ in the doxygen markup. I
was
able to change this link to one that doesn’t use ‘&’. it also looks like
this is a problem with old Doxygen format.

Hopefully, we won’t see this again or Ben can put in a quick fix for it.

I have also updated the build process such that if you specify
‘-DENABLE_DOXYGEN=False’ it does not build the swigdocs, either. So any
future problems that might occur due to issues with markup, etc., we can
at
least get around by not having these guys generated at all.

(I would also like to stop having to support Redhat, but I know too many
places are still using it.)

Tom