3.7 SWIG mess up

GNU Radio
1

Trying to load anything in gnuradio compiled from master just result in
:

Traceback (most recent call last):
File “/opt/gnuradio-3.7/bin/gr_modtool”, line 26, in
from gnuradio.modtool import *
File
“/opt/gnuradio-3.7/lib64/python2.7/site-packages/gnuradio/modtool/init.py”,
line 30, in
from modtool_newmod import ModToolNewModule
File
“/opt/gnuradio-3.7/lib64/python2.7/site-packages/gnuradio/modtool/modtool_newmod.py”,
line 27, in
from gnuradio import gr
File
“/opt/gnuradio-3.7/lib64/python2.7/site-packages/gnuradio/gr/init.py”,
line 31, in
from runtime_swig import *
File
“/opt/gnuradio-3.7/lib64/python2.7/site-packages/gnuradio/gr/runtime_swig.py”,
line 26, in
_runtime_swig = swig_import_helper()
File
“/opt/gnuradio-3.7/lib64/python2.7/site-packages/gnuradio/gr/runtime_swig.py”,
line 22, in swig_import_helper
_mod = imp.load_module(’_runtime_swig’, fp, pathname, description)
ImportError: dynamic module does not define init function
(init_runtime_swig)

I rebuilt it twice, each time starting from scratch and the last time
without any build parallelism.

Cheers,

Sylvain

2

On May 31, 2013, at 13:41, Sylvain M. [email protected] wrote:

Trying to load anything in gnuradio compiled from master just result in :

ImportError: dynamic module does not define init function (init_runtime_swig)

I rebuilt it twice, each time starting from scratch and the last time
without any build parallelism.

I have only seen this when using make -jN to build. Once it happens,
you either need to do a make clean or to start with an entirely new
build directory to ensure that the swig module in fact gets recompiled
and reinstalled. (It sounds like you did this but it wasn’t clear.)

We do have some lingering parallel build issues with swig modules.

3

Hi,

It seems that CMake couldn’t decide between the two python version
installed (I’m on gentoo and it maintains two // python tree) and
decided to use the interpreter of one with the libraries and include
path from the other. Apparently CMake is not bothered one bit by the
fact “v2.7.3” != “v3.2.3” …

I have no idea whatsoever how to fix it though …

Just in case someone else faces the issue :

-DPythonLibs_FIND_VERSION:STRING=“2.7”
-DPythonInterp_FIND_VERSION:STRING=“2.7”

Cheers,

Sylvain
4

Hi,

I have only seen this when using make -jN to build. Once it happens,
you either need to do a make clean or to start with an entirely new
build directory to ensure that the swig module in fact gets recompiled
and reinstalled. (It sounds like you did this but it wasn’t clear.)

Yes, as I said, I retried from scratch, new checkout, new builddir, I
erased everything from previous build.

I traced it to this :

//Details about finding PythonInterp
FIND_PACKAGE_MESSAGE_DETAILS_PythonInterp:INTERNAL=[/usr/bin/python][v2.7.3()]
//Details about finding PythonLibs
FIND_PACKAGE_MESSAGE_DETAILS_PythonLibs:INTERNAL=[/usr/lib64/libpython3.2.so][/usr/include/python3.2][v3.2.3()]

It seems that CMake couldn’t decide between the two python version
installed (I’m on gentoo and it maintains two // python tree) and
decided to use the interpreter of one with the libraries and include
path from the other. Apparently CMake is not bothered one bit by the
fact “v2.7.3” != “v3.2.3” …

I have no idea whatsoever how to fix it though …

Cheers,

Sylvain