CMake build problem

Gurdipe_D · April 26, 2012, 1:32pm

Hi,

I’m running debian unstable on a AMD64 platform and am running into a
problem which starts right at the top of the build process for a newly
checkout gnuradio version from git.

Below is output from running cmake:

[snip]
– Performing Test HAVE_WARN_ALL
– Performing Test HAVE_WARN_ALL - Success
– Performing Test HAVE_WARN_NO_UNINITIALIZED
– Performing Test HAVE_WARN_NO_UNINITIALIZED - Success
– Found PythonLibs:
optimized;/usr/lib/python3.2/config/libpython3.2.so;debug;/usr/lib/python3.2/config/libpython3.2.so
(found version “2.7.3rc2”)
– Found SWIG: /usr/bin/swig2.0 (found version “2.0.4”)
[snip]

So it found that /usr/bin/python is version 2.7.3rc2, but it decides
to use version 3.2 to link against. This makes the build process
rather sad later on! (Lots of link failures)

To get around this I changed in CMakeLists.txt

find_package(PythonLibs)

to be

find_package(PythonLibs 2.7.3)

But obviously that’ll only work for people running 2.7.3! (I’ve not
played with cmake before now, so there might be a simple way to fix
it)

I’m running cmake version 2.8.7.

However the build process goes further this time, but now breaks with:

[ 49%] Built target _runtime_swig_doc_tag
[ 49%] Generating doxygen xml for runtime_swig_doc docs
[ 49%] Generating runtime_swig_doc.i
[ 49%] Generating doxygen xml for general_swig_doc docs
[ 49%] Generating general_swig_doc.i
[ 49%] Generating doxygen xml for gengen_swig_doc docs
[ 49%] Generating gengen_swig_doc.i
XML parsing problem with file
/home/matt/gnuradio/20120426/gnuradio-core/src/lib/swig/gengen_swig_doc.i,
retrying.
XML parsing problem with file
/home/matt/gnuradio/20120426/gnuradio-core/src/lib/swig/gengen_swig_doc.i,
retrying.
XML parsing problem with file
/home/matt/gnuradio/20120426/gnuradio-core/src/lib/swig/gengen_swig_doc.i,
retrying.
XML parsing error with file
/home/matt/gnuradio/20120426/gnuradio-core/src/lib/swig/gengen_swig_doc.i.
giving up.
XML parsing problem with file
/home/matt/gnuradio/20120426/gnuradio-core/src/lib/swig/gengen_swig_doc.i,
retrying.
XML parsing problem with file
/home/matt/gnuradio/20120426/gnuradio-core/src/lib/swig/gengen_swig_doc.i,
retrying.
XML parsing problem with file
/home/matt/gnuradio/20120426/gnuradio-core/src/lib/swig/gengen_swig_doc.i,
retrying.
XML parsing problem with file
/home/matt/gnuradio/20120426/gnuradio-core/src/lib/swig/gengen_swig_doc.i,
retrying.
XML parsing error with file
/home/matt/gnuradio/20120426/gnuradio-core/src/lib/swig/gengen_swig_doc.i.
giving up.
XML parsing problem with file
/home/matt/gnuradio/20120426/gnuradio-core/src/lib/swig/gengen_swig_doc.i,
retrying.
XML parsing problem with file
/home/matt/gnuradio/20120426/gnuradio-core/src/lib/swig/gengen_swig_doc.i,
retrying.
XML parsing problem with file
/home/matt/gnuradio/20120426/gnuradio-core/src/lib/swig/gengen_swig_doc.i,
retrying.
XML parsing problem with file
/home/matt/gnuradio/20120426/gnuradio-core/src/lib/swig/gengen_swig_doc.i,
retrying.
XML parsing error with file
/home/matt/gnuradio/20120426/gnuradio-core/src/lib/swig/gengen_swig_doc.i.
giving up.
XML parsing problem with file
/home/matt/gnuradio/20120426/gnuradio-core/src/lib/swig/gengen_swig_doc.i,
retrying.
XML parsing problem with file
/home/matt/gnuradio/20120426/gnuradio-core/src/lib/swig/gengen_swig_doc.i,
retrying.
XML parsing problem with file
/home/matt/gnuradio/20120426/gnuradio-core/src/lib/swig/gengen_swig_doc.i,
retrying.
XML parsing problem with file
/home/matt/gnuradio/20120426/gnuradio-core/src/lib/swig/gengen_swig_doc.i,
retrying.
XML parsing error with file
/home/matt/gnuradio/20120426/gnuradio-core/src/lib/swig/gengen_swig_doc.i.
giving up.
XML parsing error with file
/home/matt/gnuradio/20120426/gnuradio-core/src/lib/swig/gengen_swig_doc.i.
giving up.
Traceback (most recent call last):
File “/home/matt/gnuradio/docs/doxygen/swig_doc.py”, line 294, in

make_swig_interface_file(di, swigdocfilename,
custom_output=custom_output)
File “/home/matt/gnuradio/docs/doxygen/swig_doc.py”, line 222, in
make_swig_interface_file
make_func = di.get_member(make_name(block.name()), DoxyFunction)
File “/home/matt/gnuradio/docs/doxygen/doxyxml/base.py”, line 157, in
get_member
raise member()
doxyxml.base.Duplicate
make[2]: *** [gnuradio-core/src/lib/swig/gengen_swig_doc.i] Error 1
make[1]: ***
[gnuradio-core/src/lib/swig/CMakeFiles/_gnuradio_core_filter.dir/all]
Error 2
make: *** [all] Error 2

Which I don’t know where to start to fix! However I can tell you that
the file its looking for, /home/…/swig/gengen_swig_doc.i doesn’t
exist, but I don’t know what should have created it.

Thanks,

Matt

unknown · April 26, 2012, 7:49pm

On Thu, Apr 26, 2012 at 7:30 AM, [email protected] wrote:

– Performing Test HAVE_WARN_ALL

it)

I’m running cmake version 2.8.7.

Yes, GNU Radio does not work with Python 3, yet. We will have to make
sure it checks that the Python version is less than 3.

XML parsing problem with file
/home/matt/gnuradio/20120426/gnuradio-core/src/lib/swig/gengen_swig_doc.i,
retrying.
XML parsing problem with file
/home/matt/gnuradio/20120426/gnuradio-core/src/lib/swig/gengen_swig_doc.i,
retrying.
File “/home/matt/gnuradio/docs/doxygen/swig_doc.py”, line 294, in

Which I don’t know where to start to fix! However I can tell you that
the file its looking for, /home/…/swig/gengen_swig_doc.i doesn’t
exist, but I don’t know what should have created it.

Thanks,

Matt

I’m assuming you are running a parallel make? Try just running “make”
with no options and see if that works. This looks like a bug that
we’ve had for a while that only shows up on occasion and when running
large parallel makes. It generally goes away when you run make again.
We thought we had squashed this one, but it seems to becoming more of
a problem again.

In the future, you can try something like “make -j8 -k”. That will
finish everything it can, even if there are errors with the doc
generation. You can then run “make” after that to capture the rest of
it.

Tom

unknown · April 26, 2012, 8:51pm

Tom R. writes:

On Thu, Apr 26, 2012 at 7:30 AM, [email protected] wrote:

Hi,

I’m running debian unstable on a AMD64 platform and am running into
a
problem which starts right at the top of the build process for a
newly
checkout gnuradio version from git.

Below is output from running cmake:

[snip]
– Performing Test HAVE_WARN_ALL
– Performing Test HAVE_WARN_ALL - Success
– Performing Test HAVE_WARN_NO_UNINITIALIZED
– Performing Test HAVE_WARN_NO_UNINITIALIZED - Success
– Found PythonLibs:
optimized;/usr/lib/python3.2/config/libpython3.2.so;debug;/usr/lib/python3.2/config/libpython3.2.so
(found version “2.7.3rc2”)
– Found SWIG: /usr/bin/swig2.0 (found version “2.0.4”)
[snip]

So it found that /usr/bin/python is version 2.7.3rc2, but it
decides
to use version 3.2 to link against. This makes the build process
rather sad later on! (Lots of link failures)

To get around this I changed in CMakeLists.txt

find_package(PythonLibs)

to be

find_package(PythonLibs 2.7.3)

But obviously that’ll only work for people running 2.7.3! (I’ve not
played with cmake before now, so there might be a simple way to fix
it)

I’m running cmake version 2.8.7.

Yes, GNU Radio does not work with Python 3, yet. We will have to make
sure it checks that the Python version is less than 3.

Getting it to try and link with the default version of python on the
system would also be good.

However the build process goes further this time, but now breaks
with:

[ 49%] Built target _runtime_swig_doc_tag
[ 49%] Generating doxygen xml for runtime_swig_doc docs
[ 49%] Generating runtime_swig_doc.i
[ 49%] Generating doxygen xml for general_swig_doc docs
[ 49%] Generating general_swig_doc.i
[ 49%] Generating doxygen xml for gengen_swig_doc docs
[ 49%] Generating gengen_swig_doc.i

[snip]

raise member()
doxyxml.base.Duplicate
make[2]: *** [gnuradio-core/src/lib/swig/gengen_swig_doc.i] Error 1
make[1]: ***
[gnuradio-core/src/lib/swig/CMakeFiles/_gnuradio_core_filter.dir/all]
Error 2
make: *** [all] Error 2

Which I don’t know where to start to fix! However I can tell you
that
the file its looking for, /home/…/swig/gengen_swig_doc.i
doesn’t
exist, but I don’t know what should have created it.

Thanks,

Matt

I’m assuming you are running a parallel make? Try just running “make”
with no options and see if that works. This looks like a bug that
we’ve had for a while that only shows up on occasion and when running
large parallel makes. It generally goes away when you run make again.
We thought we had squashed this one, but it seems to becoming more of
a problem again.

In the future, you can try something like “make -j8 -k”. That will
finish everything it can, even if there are errors with the doc
generation. You can then run “make” after that to capture the rest of
it.

Tom

Yes, I’d been doing a make -j. Rerunning with just ‘make’ doesn’t
appear to work - it fell over agaon in the same place. So I created a
new build directory, ran cmake in the new directory and then make
(with no -j) and it still fails with the above error for
gengen_swig_doc.i

Thanks,

Matt

unknown · April 26, 2012, 9:24pm

Can you try setting the PYTHON_* variables to the desired setting?

Here is a screenshot of said variables: http://i.imgur.com/kr99Q.jpg

-josh

unknown · April 26, 2012, 9:48pm

If I set the CMakeList.txt back to how it used to be and in a new
directory re-run cmake, then I get:

py_exe /usr/bin/python
py_inc /usr/include/python2.7
py_lib /usr/lib/python3.2/config/libpython3.2.so

(Which is an interesting mix!)

If I now change the py_lib variable to be
/u/l/python2.7/c/libpython2.7.so (/usr/bin/python is a sym link to
python2.7) and re-generate the make files, it
compiles the same way that my modified CMakelist.txt file (i.e. it
fails when it gets to gengen_swig_doc.i) so it certainly gets around
the python problem.

Thanks,

Matt

Josh B. writes:

Can you try setting the PYTHON_* variables to the desired setting?

Here is a screenshot of said variables: http://i.imgur.com/kr99Q.jpg

-josh

Discuss-gnuradio mailing list
[email protected]
Discuss-gnuradio Info Page

unknown · June 13, 2013, 7:13pm

I know that it’s over a year since last post; but I would like to add
new solution to the python3.2 issue.

As previous post suggested to edit CMakeLists.txt, such solution did not
work for me.

Instead edit ~/gnuradio/build/CMakeCache.txt

change all references of python3.2 to python2.7 (even if you have
python 2.7.3 installed)

then run make again. (I did not use -j option)

(for future: as time goes, your version of python (2.7,3.2) might be
different, thus adjust accordingly)