I spend some more time on figuring out what is going on.

It looks like the SWIG example from () works properly. I am able to check
if SWIG has correctly incorporated the 'example.c' extension:
>>> import example
>>> example.fact(4)
24
>>> dir(example)
['__builtins__', '__doc__', '__file__', '__name__', '__package__',
'_example', '_newclass', '_object', '_swig_getattr',
'_swig_getattr_nondynamic', '_swig_property', '_swig_repr',
'_swig_setattr', '_swig_setattr_nondynamic', 'fact']


However, when I do the same thing for my GRC custom module, 'a1System' I
don't see anything relevant to SWIG at all. It looks like somewhere the
SWIG doesn't work properly in my environment and needs a fix. You can see
that none of the 'swig_*' functions are seen in the a1System module. I
would expect to see something similar to what was seen in the above example
of SWIG tutorial. Something is definitely wrong with SWIG/PYTHON/GRC work
environment.

Anything else I can check for?

>>> import a1System
>>> dir(a1System)
['__builtins__', '__doc__', '__file__', '__name__', '__package__',
'__path__']

Vipin


On Thu, Jul 13, 2017 at 10:04 PM, Vipin Sharma <[email protected]>
wrote:

> 1. This one I checked already. I don't explicitly include any external
> libraries.
> 2. I eyeballed the cmake .. output again (see below). I don't see anything
> obviously missing.
>
> You mentioned something about SWIG. I have no idea what SWIG does and how
> to check it is indeed working properly. Can you point me to some
> documentation of what SWIG is and how it works with Python/Gnuradio?
>
> Anything else I can try from this point?
>
> -- The CXX compiler identification is GNU 5.4.0
> -- The C compiler identification is GNU 5.4.0
> -- Check for working CXX compiler: /usr/bin/c++
> -- Check for working CXX compiler: /usr/bin/c++ -- works
> -- Detecting CXX compiler ABI info
> -- Detecting CXX compiler ABI info - done
> -- Detecting CXX compile features
> -- Detecting CXX compile features - done
> -- Check for working C compiler: /usr/bin/cc
> -- Check for working C compiler: /usr/bin/cc -- works
> -- Detecting C compiler ABI info
> -- Detecting C compiler ABI info - done
> -- Detecting C compile features
> -- Detecting C compile features - done
> -- Build type not specified: defaulting to release.
> -- Boost version: 1.58.0
> -- Found the following Boost libraries:
> --   filesystem
> --   system
> -- Found PkgConfig: /usr/bin/pkg-config (found version "0.29.1")
> -- Checking for module 'cppunit'
> --   Found cppunit, version 1.13.2
> -- Found CPPUNIT: /usr/lib/x86_64-linux-gnu/libcppunit.so;dl
> -- Found Doxygen: /usr/local/bin/doxygen (found version "1.8.14")
> Checking for GNU Radio Module: RUNTIME
> -- Checking for module 'gnuradio-runtime'
> --   Found gnuradio-runtime, version 3.7.11.1
>  * INCLUDES=/usr/local/include
>  * LIBS=/usr/local/lib/libgnuradio-runtime.so;/usr/
> local/lib/libgnuradio-pmt.so
> -- Found GNURADIO_RUNTIME: /usr/local/lib/libgnuradio-
> runtime.so;/usr/local/lib/libgnuradio-pmt.so
> GNURADIO_RUNTIME_FOUND = TRUE
> -- Found Git: /usr/bin/git
> -- Using install prefix: /usr/local
> -- Building for version: v1.0-compat-xxx-xunknown / 1.0.0git
> --
> -- Checking for module SWIG
> -- Found SWIG version 3.0.8.
> -- Found SWIG: /usr/bin/swig3.0
> -- Found PythonLibs: /usr/lib/x86_64-linux-gnu/libpython2.7.so (found
> suitable version "2.7.12", minimum required is "2")
> -- Found PythonInterp: /usr/bin/python2 (found suitable version "2.7.12",
> minimum required is "2")
> -- Looking for sys/types.h
> -- Looking for sys/types.h - found
> -- Looking for stdint.h
> -- Looking for stdint.h - found
> -- Looking for stddef.h
> -- Looking for stddef.h - found
> -- Check size of size_t
> -- Check size of size_t - done
> -- Check size of unsigned int
> -- Check size of unsigned int - done
> -- Performing Test HAVE_WNO_UNUSED_BUT_SET_VARIABLE
> -- Performing Test HAVE_WNO_UNUSED_BUT_SET_VARIABLE - Success
> -- Configuring done
> -- Generating done
> -- Build files have been written to: /home/vipin/a1/grcnew/gr-
> a1System/build
>
>
> On Sun, Jul 9, 2017 at 11:43 PM, Nicolas Cuervo <[email protected]>
> wrote:
>
>> There are two things worth checking as of now, before getting into the
>> specifics:
>>
>> 1. You have all the libraries that your module need, and they are
>> properly linked: this is part of your first answer to this thread. If you
>> included external/custom libraries, that is the ones that you'd need to
>> manually link
>> 2. Your swig installation exists and its working: sometimes (maybe
>> always? not sure anymore) the compilation of your module succeed even if
>> you don't have SWIG working, and it leads to issues like this. Read the
>> output of the 'cmake ..' step to check if it tells that that something is
>> missing.
>>
>> -N
>>
>> On Mon, Jul 10, 2017 at 8:08 AM, Vipin Sharma <[email protected]
>> > wrote:
>>
>>> Thanks for your quick post. Looks like it cannot find the custom block
>>> in standalone Python as well. I have followed the custom block OOT module
>>> tutorial verbatim; I don't think I saw any issues with any of the outlined
>>> steps in the guided tutorial.
>>>
>>> There seems to be some installation issue for the custom block during
>>> 'sudo make install' step of the guided tutorial?
>>>
>>> Python 2.7.12 (default, Nov 19 2016, 06:48:10)
>>> [GCC 5.4.0 20160609] on linux2
>>> Type "help", "copyright", "credits" or "license" for more information.
>>> >>> import a1System
>>> >>> from a1System import TargetDetector_cf
>>> Traceback (most recent call last):
>>>   File "<stdin>", line 1, in <module>
>>> ImportError: cannot import name TargetDetector_cf
>>> >>>
>>>
>>>
>>>
>>> On Sun, Jul 9, 2017 at 11:04 PM, Nicolas Cuervo <
>>> [email protected]> wrote:
>>>
>>>> Hello Vipin,
>>>>
>>>> Just as a sanity check (from some funny behaviour that I saw recently):
>>>> can you actually import that module in a python interpreter (such as
>>>> ipython or bpython)? I.e. are you able to do the following?
>>>>
>>>>     >>> import a1System
>>>>     >>> from a1System import TargetDetector_cf
>>>>
>>>>
>>>>
>>>> On Mon, Jul 10, 2017 at 7:59 AM, <[email protected]> wrote:
>>>>
>>>>> I tried ‘sudo ldconfig’ and then regenerated the flowgraph after
>>>>> re-building the application. I see the same issue as before. Here is the
>>>>> output of ‘ldd’. How do I know what is missing?
>>>>>
>>>>>
>>>>>
>>>>>                 linux-vdso.so.1 =>  (0x00007ffc10dfd000)
>>>>>
>>>>>                 libboost_system.so.1.58.0 =>
>>>>> /usr/lib/x86_64-linux-gnu/libboost_system.so.1.58.0
>>>>> (0x00007fc09f77b000)
>>>>>
>>>>>                 libgnuradio-runtime-3.7.11.1.so.0.0.0 =>
>>>>> /usr/local/lib/libgnuradio-runtime-3.7.11.1.so.0.0.0
>>>>> (0x00007fc09f48f000)
>>>>>
>>>>>                 libgnuradio-pmt-3.7.11.1.so.0.0.0 =>
>>>>> /usr/local/lib/libgnuradio-pmt-3.7.11.1.so.0.0.0 (0x00007fc09f23f000)
>>>>>
>>>>>                 libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6
>>>>> (0x00007fc09eebd000)
>>>>>
>>>>>                 libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6
>>>>> (0x00007fc09ebb4000)
>>>>>
>>>>>                 libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1
>>>>> (0x00007fc09e99d000)
>>>>>
>>>>>                 libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6
>>>>> (0x00007fc09e5d3000)
>>>>>
>>>>>                 libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0
>>>>> (0x00007fc09e3b6000)
>>>>>
>>>>>                 libvolk.so.1.3 => /usr/local/lib/libvolk.so.1.3
>>>>> (0x00007fc09dfea000)
>>>>>
>>>>>                 libboost_program_options.so.1.58.0 =>
>>>>> /usr/lib/x86_64-linux-gnu/libboost_program_options.so.1.58.0
>>>>> (0x00007fc09dd6c000)
>>>>>
>>>>>                 libboost_filesystem.so.1.58.0 =>
>>>>> /usr/lib/x86_64-linux-gnu/libboost_filesystem.so.1.58.0
>>>>> (0x00007fc09db54000)
>>>>>
>>>>>                 libboost_thread.so.1.58.0 =>
>>>>> /usr/lib/x86_64-linux-gnu/libboost_thread.so.1.58.0
>>>>> (0x00007fc09d92d000)
>>>>>
>>>>>                 librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1
>>>>> (0x00007fc09d725000)
>>>>>
>>>>>                 /lib64/ld-linux-x86-64.so.2 (0x000055ff2d4b7000)
>>>>>
>>>>>                 liborc-0.4.so.0 => 
>>>>> /usr/lib/x86_64-linux-gnu/liborc-0.4.so.0
>>>>> (0x00007fc09d4a4000)
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Sent from Mail <https://go.microsoft.com/fwlink/?LinkId=550986> for
>>>>> Windows 10
>>>>>
>>>>>
>>>>>
>>>>> *From: *Nicolas Cuervo <[email protected]>
>>>>> *Sent: *Sunday, July 9, 2017 10:49 PM
>>>>> *To: *Vipin Sharma <[email protected]>
>>>>> *Cc: *GNURadio Discussion List <[email protected]>
>>>>> *Subject: *Re: [Discuss-gnuradio] Runtime AttributeError for custom
>>>>> block
>>>>>
>>>>>
>>>>>
>>>>> Hi,
>>>>>
>>>>>
>>>>>
>>>>> it is nice that you look for the error before posting, but does your
>>>>> module actually need the ITPP libraries? because that might have been
>>>>> something specific for the case that you quoted.
>>>>>
>>>>> To check if your problem is linking, first run the following command:
>>>>>
>>>>>
>>>>>
>>>>>     $ sudo ldconfig
>>>>>
>>>>>
>>>>>
>>>>> and then try to start again your application in GRC.
>>>>>
>>>>>
>>>>>
>>>>> If the problem persists, then you have to look for some required
>>>>> library which linking is not made properly. To check the linking you can
>>>>> run the "ldd" command on the generated shared object of your module 
>>>>> (which,
>>>>> based on your email, is supposed to be called something like
>>>>> 'libgnuradio-a1System.so')
>>>>>
>>>>> Regards,
>>>>>
>>>>> - Nicolas
>>>>>
>>>>>
>>>>>
>>>>> On Mon, Jul 10, 2017 at 6:31 AM, Vipin Sharma <
>>>>> [email protected]> wrote:
>>>>>
>>>>> I have a Python flowgraph which instantiates a few custom blocks
>>>>> (written in C++). The flow graph generate is fine but when I try to run 
>>>>> the
>>>>> program through GUI, I get attribute errors as shown below.
>>>>>
>>>>>
>>>>>
>>>>> After researching a bit, I found out that one potential cause could be
>>>>> missing ITPP libraries as discussed in an old post here:
>>>>> https://lists.gnu.org/archive/html/discuss-gnuradio/20
>>>>> 15-02/msg00158.html.
>>>>>
>>>>>
>>>>>
>>>>> I followed through suggested changes (adding following lines in my
>>>>> lib/CMakeList.txt). This doesn't seem to help at all; I don't see any 
>>>>> extra
>>>>> libraries being included in the final a1System.so library under build/lib/
>>>>> after the 'make build'. This likely implies I am still missing a critical
>>>>> step for the custom blocks in C++. Any ideas how I can proceed?
>>>>>
>>>>>
>>>>>
>>>>> Excerpt from lib/CMakeList.txt file:
>>>>>
>>>>>
>>>>>
>>>>> list(APPEND a1System_libs
>>>>>
>>>>>  ${GNURADIO_ALL_LIBRARIES}
>>>>>
>>>>>  ${ITPP_LIBRARIES}
>>>>>
>>>>> )
>>>>>
>>>>> target_link_libraries(gnuradio-a1System ${Boost_LIBRARIES}
>>>>> ${a1System_libs})
>>>>>
>>>>>
>>>>>
>>>>> Runtime Log from GRC:
>>>>>
>>>>>
>>>>>
>>>>> File "/home/vipin/a1/grc/a1-rfe+mimo/gr-a1System/build/top_block.py", 
>>>>> line 234, in <module>
>>>>>
>>>>> main()
>>>>>
>>>>> File "/home/vipin/a1/grc/a1-rfe+mimo/gr-a1System/build/top_block.py", 
>>>>> line 222, in main
>>>>>
>>>>> tb = top_block_cls()
>>>>>
>>>>> File "/home/vipin/a1/grc/a1-rfe+mimo/gr-a1System/build/top_block.py", 
>>>>> line 164, in __init__
>>>>>
>>>>> self.a1System_TargetDetector_cf_0 = a1System.TargetDetector_cf(512, 10, 
>>>>> 1024, 2, 5, 1, 1, 1, 1)
>>>>>
>>>>> AttributeError: 'module' object has no attribute 'TargetDetector_cf'
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Discuss-gnuradio mailing list
>>>>> [email protected]
>>>>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>
>
_______________________________________________
Discuss-gnuradio mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Reply via email to