AttributeError: 'module' object has no attribute 'hamming'

GNU Radio
1

Hi ,
I wrote a Out of Tree module for hamming code using ITPP library . It
compiled when i ran the cmake… , make and make install commands without
error . I used the block in a flowgraph and the python script thus
generated throws an error while executing it which looks like this .

Traceback (most recent call last):
File “/home/iiitd/Desktop/hamming.py”, line 62, in
tb = hamming()
File “/home/iiitd/Desktop/hamming.py”, line 33, in init
self.wsi_hamming_0 = wsi.hamming(3)
AttributeError: ‘module’ object has no attribute ‘hamming’

I then checked the $PYTHONPATH and made sure it points to the directory
where the files associated with the block are installed during make
install
ie /usr/local/lib/python2.7/dist-packages instead to
/opt/qt/lib/python2.7/dist-packages .

It would be really thankful if somebody helps me sort this out .

The link to the my OOT code is
https://www.dropbox.com/sh/8tstm4ckaphsis/AAD0cbS5eelaoaIe0gUExCBea?dl=0

Thanks
Abhinav J.

2

I ran into this myself with a custom Python block. I was unable to
resolve it. I gave up. Interested to learn a fix as well.

3

On Sat, Feb 14, 2015 at 2:17 AM, Abhinav J.
[email protected]
wrote:

self.wsi_hamming_0 = wsi.hamming(3)

The link to the my OOT code is
Dropbox - Error - Simplify your life

Thanks
Abhinav J.

Did you use gr_modtool to build the OOT project?

Are you sure you are linking against the ITPP library correctly? If you
ldd
on your resulting .so file, does it show it links properly?

Is your block in Python or in C++?

What version of GNU Radio are you running?

That link you sent goes nowhere.

You can run “gdb --args python hamming.py” to see a backtrace of where
the
problem is really happening.

Tom

4

Hi ,
Sorry for not providing all the info . I dont know what happened to the
link though .
I used gr_modtool to create the OOT module ;
I wrote the module in C++ and i am using GNU Radio 3.7.6
I have created a git repository :

ldd on the .so file has the following output .
iiitd@iiitd-ThinkPad-W530:/usr/local/lib$ ldd libgnuradio-wsi.so
linux-vdso.so.1 => (0x00007fffc59fe000)
libboost_system.so.1.53.0 =>
/usr/lib/x86_64-linux-gnu/libboost_system.so.1.53.0 (0x00007f79fc959000)
libgnuradio-runtime-3.7.6.1.so.0.0.0 =>
/usr/local/lib/libgnuradio-runtime-3.7.6.1.so.0.0.0 (0x00007f79fc689000)
libgnuradio-pmt-3.7.6.1.so.0.0.0 =>
/usr/local/lib/libgnuradio-pmt-3.7.6.1.so.0.0.0 (0x00007f79fc440000)
libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6
(0x00007f79fc13c000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1
(0x00007f79fbf26000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f79fbb5d000)
libvolk.so.0.0.0 => /usr/local/lib/libvolk.so.0.0.0
(0x00007f79fb80f000)
libboost_filesystem.so.1.53.0 =>
/usr/lib/x86_64-linux-gnu/libboost_filesystem.so.1.53.0
(0x00007f79fb5f9000)
libboost_thread.so.1.53.0 =>
/usr/lib/x86_64-linux-gnu/libboost_thread.so.1.53.0 (0x00007f79fb3e2000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0
(0x00007f79fb1c5000)
liblog4cpp.so.5 => /usr/lib/liblog4cpp.so.5 (0x00007f79faf85000)
librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007f79fad7c000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f79faa78000)
/lib64/ld-linux-x86-64.so.2 (0x00007f79fcd87000)
liborc-0.4.so.0 => /usr/lib/x86_64-linux-gnu/liborc-0.4.so.0
(0x00007f79fa7f8000)
libnsl.so.1 => /lib/x86_64-linux-gnu/libnsl.so.1
(0x00007f79fa5de000)

While running gdb --args python hamming.py has the following result .
(gdb) run
Starting program: /usr/bin/python hamming.py
[Thread debugging using libthread_db enabled]
Using host libthread_db library
“/lib/x86_64-linux-gnu/libthread_db.so.1”.
[New Thread 0x7fffe2576700 (LWP 4704)]
[New Thread 0x7fffe1d75700 (LWP 4705)]
[New Thread 0x7fffe0a9a700 (LWP 4706)]
[New Thread 0x7fffd3fff700 (LWP 4707)]
[New Thread 0x7fffd37fe700 (LWP 4708)]
Traceback (most recent call last):
File “hamming.py”, line 62, in
tb = hamming()
File “hamming.py”, line 33, in init
self.wsi_hamming_0 = wsi.hamming(3)
AttributeError: ‘module’ object has no attribute ‘hamming’
[Thread 0x7fffd37fe700 (LWP 4708) exited]
[Thread 0x7fffe0a9a700 (LWP 4706) exited]
[Thread 0x7fffe1d75700 (LWP 4705) exited]
[Thread 0x7fffe2576700 (LWP 4704) exited]
[Thread 0x7ffff7fd6740 (LWP 4699) exited]
[Inferior 1 (process 4699) exited with code 01]

Thanks in advance
Abhinav J.

5

On Sat, Feb 14, 2015 at 6:41 PM, Richard B. [email protected]
wrote:

I ran into this myself with a custom Python block. I was unable to resolve
it. I gave up. Interested to learn a fix as well.

I don’t think this is a Python block since he’s linking against ITPP,
but
it’s not specified in his original question, so I can’t be sure.

Anyways, I just tried making a Python block in an OOT project and it
works
just fine.

$ gr_modtool nm
Name of the new module: testpy
Creating out-of-tree module in ./gr-testpy… Done.
Use ‘gr_modtool add’ to add a new block to this currently empty module.

$ cd gr-testpy
$ gr_modtool add
GNU Radio module name identified: testpy
(‘sink’, ‘source’, ‘sync’, ‘decimator’, ‘interpolator’, ‘general’,
‘tagged_stream’, ‘hier’, ‘noblock’)
Enter block type: sync
Language (python/cpp): python
Language: Python
Enter name of block/code (without module name prefix): test01
Block/code identifier: test01
Enter valid argument list, including default arguments:
Add Python QA code? [Y/n]
Adding file ‘python/test01.py’…
Adding file ‘python/qa_test01.py’…
Editing python/CMakeLists.txt…
Adding file ‘grc/testpy_test01.xml’…
Editing grc/CMakeLists.txt…

$ mkdir build; cd build
$ cmake -DCMAKE_INSTALL_PREFIX=/opt/gr …/
$ make
$ make install
$ ipython
In [1]: import testpy

In [2]: dir(testpy)
Out[2]:
[‘builtins’,
‘doc’,
‘file’,
‘name’,
‘package’,
‘path’,
‘test01’]

In [3]: a = testpy.test01()

Worked fine. You’re not the only person with this problem, but no one
has
yet shown me how to reproduce the error.

Tom

6

On Tue, Feb 17, 2015 at 11:04 AM, Abhinav J.
[email protected]
wrote:

linux-vdso.so.1 =>  (0x00007fffc59fe000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f79fbb5d000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f79faa78000)
/lib64/ld-linux-x86-64.so.2 (0x00007f79fcd87000)
liborc-0.4.so.0 => /usr/lib/x86_64-linux-gnu/liborc-0.4.so.0

(0x00007f79fa7f8000)
libnsl.so.1 => /lib/x86_64-linux-gnu/libnsl.so.1 (0x00007f79fa5de000)

Yep, that tells you it right there. You are not linking against the ITPP
library. Here’s the change you need to make to your lib/CMakeLists.txt
file:

add_library(gnuradio-wsi SHARED ${wsi_sources})
-target_link_libraries(gnuradio-wsi ${Boost_LIBRARIES}
${GNURADIO_ALL_LIBRARIES})
+target_link_libraries(gnuradio-wsi ${Boost_LIBRARIES} ${wsi_libs})
set_target_properties(gnuradio-wsi PROPERTIES DEFINE_SYMBOL
“gnuradio_wsi_EXPORTS”)

You’ve created a wsi_libs variable already, but never added this to the
target_link_libraries call. So when trying to open the shared library
and
make ITPP calls, you couldn’t, which was causing the import to fail.
Notice
all of the extra libraries it links against when you make this change
(libitpp.so, libblas.so, etc., etc.):

$ ldd lib/libgnuradio-wsi.so
linux-vdso.so.1 => (0x00007fff5d8a1000)
libboost_system.so.1.54.0 =>
/usr/lib/x86_64-linux-gnu/libboost_system.so.1.54.0 (0x00007f9228b6f000)
libgnuradio-runtime-3.7.7git.so.0.0.0 =>
/opt/gr/lib/libgnuradio-runtime-3.7.7git.so.0.0.0 (0x00007f922889f000)
libgnuradio-pmt-3.7.7git.so.0.0.0 =>
/opt/gr/lib/libgnuradio-pmt-3.7.7git.so.0.0.0 (0x00007f9228657000)
libitpp.so.8 => /usr/lib/libitpp.so.8 (0x00007f9228088000)
libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6
(0x00007f9227d83000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1
(0x00007f9227b6d000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f92277a7000)
libvolk.so.0.0.0 => /opt/gr/lib/libvolk.so.0.0.0 (0x00007f9227481000)
libboost_filesystem.so.1.54.0 =>
/usr/lib/x86_64-linux-gnu/libboost_filesystem.so.1.54.0
(0x00007f922726b000)
libboost_thread.so.1.54.0 =>
/usr/lib/x86_64-linux-gnu/libboost_thread.so.1.54.0 (0x00007f9227055000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0
(0x00007f9226e36000)
liblog4cpp.so.5 => /usr/lib/liblog4cpp.so.5 (0x00007f9226bf6000)
librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007f92269ee000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f92266e7000)
libfftw3.so.3 => /usr/lib/x86_64-linux-gnu/libfftw3.so.3
(0x00007f92262ef000)
liblapack.so.3 => /usr/lib/liblapack.so.3 (0x00007f9225b53000)
libblas.so.3 => /usr/lib/libblas.so.3 (0x00007f9225586000)
libgomp.so.1 => /usr/lib/x86_64-linux-gnu/libgomp.so.1
(0x00007f9225377000)
/lib64/ld-linux-x86-64.so.2 (0x00007f9228fb1000)
liborc-0.4.so.0 => /usr/lib/x86_64-linux-gnu/liborc-0.4.so.0
(0x00007f92250f5000)
libnsl.so.1 => /lib/x86_64-linux-gnu/libnsl.so.1 (0x00007f9224eda000)
libgfortran.so.3 => /usr/lib/x86_64-linux-gnu/libgfortran.so.3
(0x00007f9224bc1000)
libquadmath.so.0 => /usr/lib/x86_64-linux-gnu/libquadmath.so.0
(0x00007f9224984000)

I was hoping that the gdb call would tell us of the failure going on in
inside the module while it was trying to import it, but looks like
that’s
opaque here. Oh well.

Also, just as an aside, your git needs a bit of work. You’ve added the
build directory, which you should never do, as well as all of your
temporary emacs files (the files ending in ~). And for some reason, your
root directory is Documents with gr-wsi underneath. Just some tips to
make
it easier to share your code in the future.

Tom