On Tue, Feb 17, 2015 at 11:04 AM, Abhinav Jadon <abhinav12...@iiitd.ac.in> wrote:
> 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 : > https://github.com/Jadoobaba/gr-wsi/tree/master/Documents/gr-wsi > > 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) > 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 > 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 <module> > 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 Jadon > > > > On Tue, Feb 17, 2015 at 8:37 PM, Tom Rondeau <t...@trondeau.com> wrote: > >> On Sat, Feb 14, 2015 at 6:41 PM, Richard Bell <richard.be...@gmail.com> >> 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... >> >> <edited the test01.py file and set it to use float input and float output> >> >> $ 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 >> >> >> >>> On Feb 13, 2015, at 11:17 PM, Abhinav Jadon <abhinav12...@iiitd.ac.in> >>> wrote: >>> >>> 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 <module> >>> 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 Jadon >>> >>> >> > > > -- > Abhinav PS Jadon > 2012122 > Btech 2016-ECE > >
_______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
