ysf example problem

[sv1]

Hello Matt,

please see the problem below, when I try to execute ysf_rx.grc

Generating: "/opt/linux/gr-ysf/examples/top_block.py"

Executing: "/opt/linux/gr-ysf/examples/top_block.py"

linux; GNU C++ version 4.9.1; Boost_105500; UHD_003.007.003-0-unknown

Traceback (most recent call last): File "/opt/linux/gr-ysf/examples/top_block.py", line 575, in tb = top_block() File "/opt/linux/gr-ysf/examples/top_block.py", line 99, in init self.ysf_vd2_vch_decoder_bb_0 = ysf.vd2_vch_decoder_bb() AttributeError: 'module' object has no attribute 'vd2_vch_decoder_bb'

Done

Regards Apostolos

[mweyland]

Apparently python is not able to find the vd2_vch_decoder_bb block. The most common cause for this is when swig is not installed. I guess I should write this down somewhere. Can you maybe check if you have swig installed? Debian should have a swig2.0 package that you can install with apt-get / aptitude. Then rm -rf build, mkdir build, cd build, cmake .., make and make install (last one as root) as usual.

Could you report back if that fixed the problem? I think cmake gives a warning about this but it's easy to overlook it. If that was the problem I'll put it in the documentation. Thank you, Matt

[sv1]

Hello Matt,

$ swig -version

SWIG Version 2.0.12

Compiled with g++ [x86_64-unknown-linux-gnu]

Configured options: +pcre

Please see http://www.swig.org for reporting bugs and further information

Nope!!! that is not the problem..

On Πεμ, 2015-11-12 at 11:02 -0800, mweyland wrote:

Apparently python is not able to find the vd2_vch_decoder_bb block. The most common cause for this is when swig is not installed. I guess I should write this down somewhere. Can you maybe check if you have swig installed? Debian should have a swig2.0 package that you can install with apt-get / aptitude. Then rm -rf build, mkdir build, cd build, cmake .., make and make install (last one as root) as usual.

Could you report back if that fixed the problem? I think cmake gives a warning about this but it's easy to overlook it. If that was the problem I'll put it in the documentation. Thank you, Matt

— Reply to this email directly or view it on GitHub.Web Bug from https://github.com/notifications/beacon/AFRSQ86s8_M_PKvwJKz8WBC-0Zqgvno2ks5pFNnEgaJpZM4GhQVm.gif

Κεφάλας Απόστολος - SV1LJJ Γραμματέας ΕΚΕΑν Τοπικός Σύνδεσμος Αττικής τηλ: +30 6979 976 039 Echolink id: 309275 skype: apostolis.kef sip:apkefalas@iptel.org PGP: 0xA3C19DA0

[sv1]

$ grep -i -r "vd2_vch_decoder_bb()" * examples/top_block.py: self.ysf_vd2_vch_decoder_bb_0 = ysf.vd2_vch_decoder_bb() grc/ysf_vd2_vch_decoder_bb.xml: ysf.vd2_vch_decoder_bb()

Maybe, something is missing ?!?!?!

73 Apostolos

On Πεμ, 2015-11-12 at 11:02 -0800, mweyland wrote:

Apparently python is not able to find the vd2_vch_decoder_bb block. The most common cause for this is when swig is not installed. I guess I should write this down somewhere. Can you maybe check if you have swig installed? Debian should have a swig2.0 package that you can install with apt-get / aptitude. Then rm -rf build, mkdir build, cd build, cmake .., make and make install (last one as root) as usual.

Could you report back if that fixed the problem? I think cmake gives a warning about this but it's easy to overlook it. If that was the problem I'll put it in the documentation. Thank you, Matt

— Reply to this email directly or view it on GitHub.Web Bug from https://github.com/notifications/beacon/AFRSQ86s8_M_PKvwJKz8WBC-0Zqgvno2ks5pFNnEgaJpZM4GhQVm.gif

[mweyland]

Hm OK blaming it on a missing swig would have been too easy. gnuradio handles this is as follows: The blocks written in C++ (such as all of the gr-ysf custom blocks) are made accessible by providing a python wrapper. This is where swig comes into play -- swig allows you to use C++ stuff from python. That way, we have the 'ease' of python while the hard work is still done in C++. You can see this as follows:

$ python
Python 2.7.6 (default, Jun 22 2015, 17:58:13) 
[GCC 4.8.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import ysf
>>> ysf.vd2_vch_decoder_bb
<function make at 0x7fb0e3be75f0>

On my system, the thing that I am importing is /usr/local/lib/python2.7/dist-packages/ysf/__init__.py which in turn pulls in ysf_swig.py in the same directory. This will then provide the bindings to interact with the blocks that are all compiled into /usr/local/lib/libgnuradio-ysf.so. Maybe that shared library could not be found. Running ldconfig as root should address that. It would be interesting to see what happens when you try to import ysf manually from a python2 shell (exactly like I did above) and the ldd output on libgnuradio-ysf.so. Mine is as follows:

$ ldd /usr/local/lib/libgnuradio-ysf.so
    linux-vdso.so.1 =>  (0x00007ffc7c785000)
    libboost_system.so.1.54.0 => /usr/lib/x86_64-linux-gnu/libboost_system.so.1.54.0 (0x00007fee9779e000)
    libgnuradio-runtime.so.3.7.5 => /usr/lib/x86_64-linux-gnu/libgnuradio-runtime.so.3.7.5 (0x00007fee974ca000)
    libgnuradio-pmt.so.3.7.5 => /usr/lib/x86_64-linux-gnu/libgnuradio-pmt.so.3.7.5 (0x00007fee97282000)
    libmbe.so.1 => /usr/local/lib/libmbe.so.1 (0x00007fee97062000)
    libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007fee96d5e000)
    libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007fee96b47000)
    libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fee96782000)
    libvolk.so.0.0.0 => /usr/lib/x86_64-linux-gnu/libvolk.so.0.0.0 (0x00007fee9647b000)
    libboost_filesystem.so.1.54.0 => /usr/lib/x86_64-linux-gnu/libboost_filesystem.so.1.54.0 (0x00007fee96264000)
    libboost_thread.so.1.54.0 => /usr/lib/x86_64-linux-gnu/libboost_thread.so.1.54.0 (0x00007fee9604e000)
    libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007fee95e30000)
    liblog4cpp.so.5 => /usr/lib/liblog4cpp.so.5 (0x00007fee95bef000)
    librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007fee959e7000)
    libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007fee956e1000)
    /lib64/ld-linux-x86-64.so.2 (0x00007fee97be5000)
    liborc-0.4.so.0 => /usr/lib/x86_64-linux-gnu/liborc-0.4.so.0 (0x00007fee9545e000)
    libnsl.so.1 => /lib/x86_64-linux-gnu/libnsl.so.1 (0x00007fee95244000)

If the problem doesn't become apparent by then and/or ldconfig doesn't fix it, I'd be interested in your cmake output as well as in the verbose build log. You can generate this by running VERBOSE=1 make 2>&1 | tee build.log.txt. I'm attaching mine for comparison.

Thanks for trying :). Regards, Matt

matt_cmake.log.txt matt_build.log.txt

[sv1]

On Παρ, 2015-11-13 at 05:10 -0800, mweyland wrote:

Hm OK blaming it on a missing swig would have been too easy. gnuradio handles this is as follows: The blocks written in C++ (such as all of the gr-ysf custom blocks) are made accessible by providing a python wrapper. This is where swig comes into play -- swig allows you to use C++ stuff from python. That way, we have the 'ease' of python while the hard work is still done in C++. You can see this as follows:

$ python Python 2.7.6 (default, Jun 22 2015, 17:58:13) [GCC 4.8.2] on linux2 Type "help", "copyright", "credits" or "license" for more information.

import ysf ysf.vd2_vch_decoder_bb <function make at 0x7fb0e3be75f0>

On my system, the thing that I am importing is /usr/local/lib/python2.7/dist-packages/ysf/init.py which in turn pulls in ysf_swig.py in the same directory. This will then provide the bindings to interact with the blocks that are all compiled into /usr/local/lib/libgnuradio-ysf.so. Maybe that shared library could not be found. Running ldconfig as root should address that.

Thanks Matt,

ldconfig did the trick!

Apostolos