Perfect, Thank you everyone. What I did was include the header files in my block source files; I needed to add them to the CMakeLists.txt in /lib under: list(APPEND router_sources to get everything to build and link correctly.
I was then able to import the module and use it without error in python. From
now on I will use 'no block'.
---------
The next question I have is... is there any documentation on creating GNU Radio
programs in c++ including the build instructions? I want to test my code in a
c++ program as well. I saw the example dial_tone, but I'm not sure what else I
need to include to build it. dial_tone also doesn't seem to work in my virtual
machine with the following error:
tjt7a@ubuntu:~/Src/pybombs/src/gnuradio$
./build/gr-audio/examples/c++/dial_tone
audio_oss_sink: /dev/dsp: No such file or directory
terminate called after throwing an instance of 'std::runtime_error'
what(): audio_oss_sink
Aborted (core dumped)
Sincerely,
Tommy James Tracy II
Ph.D Student
High Performance Low Power Lab
University of Virginia
Phone: 913-775-2241
On Sep 21, 2013, at 11:21 AM, Tom Rondeau <t...@trondeau.com> wrote:
> On Fri, Sep 20, 2013 at 7:13 PM, Martin Braun (CEL)
> <martin.br...@kit.edu> wrote:
>> Hi Tommy,
>>
>> is this a visibility issue? Did you use modtool to add the additional
>> classes? If not, do you have a FOO_API macro in your class def?
>>
>> MB
>
> Tommy,
>
> Yes, make sure that the FOO_API is declared for the classes. Also, you
> have to make sure they are being imported into the swig module
> correctly in gr-foo/swig/foo_swig.i.
>
> You can use gr_modtool with the class type "noblock" to create classes
> that are not gr::blocks for this purpose, which will set up the cmake
> and swig files correctly.
>
>
>> On Fri, Sep 20, 2013 at 01:58:16PM -0400, Tommy Tracy II wrote:
>>> Dear List,
>>>
>>>
>>> I am using gr_modtool to create new modules and blocks, and I have a
>>> question
>>> about adding additional .cc/.h files that are not included by gr_modtool to
>>> the
>>> cmake file or otherwise importing them by hand.
>>>
>>>
>>> My new blocks are dependent on two new classes called
>>> NetworkInterface.{cc,h}
>>> and EthernetConnector.{cc,h}. During the make process, if there is a syntax
>>> error in either of these files, the compiler will alert me. I was able to
>>> fix
>>> all problems and get the cmake, make, and make install completed. The
>>> problem
>>> manifested itself when I attempted to import the module:
>>>
>>> ----------
>>>
>>>>>> import router
>>>
>>> Traceback (most recent call last):
>>>
>>> File "<stdin>", line 1, in <module>
>>>
>>> File
>>> "/home/tjt7a/Src/target/lib/python2.7/dist-packages/router/__init__.py",
>>> line 45, in <module>
>>>
>>> from router_swig import *
>>>
>>> File "/home/tjt7a/Src/target/lib/python2.7/dist-packages/router/
>>> router_swig.py", line 26, in <module>
>>>
>>> _router_swig = swig_import_helper()
>>>
>>> File "/home/tjt7a/Src/target/lib/python2.7/dist-packages/router/
>>> router_swig.py", line 22, in swig_import_helper
>>>
>>> _mod = imp.load_module('_router_swig', fp, pathname, description)
>>>
>>> ImportError: /home/tjt7a/Src/target/lib/libgnuradio-router.so: undefined
>>> symbol: _ZN16NetworkInterface7connectEPc
>>>
>>> ----------
>>>
>>> To investigate the definition of this symbol, I ran c++filt
>>>
>>> ----------
>>>
>>> $c++filt _ZN16NetworkInterface7connectEPc
>>>
>>> NetworkInterface::connect(char*)
>>>
>>> ----------
>>>
>>> This indicates, that my libgnuradio-router module cannot access the
>>> NetworkInterface object file, even though it was part of the compilation
>>> step.
>>>
>>>
>>> My thought process was to create the two shared object (.so) files by hand,
>>> and
>>> move them to my python path location. So I did that:
>>>
>>> ----------
>>>
>>> cc -shared -o libEthernetConnector.so -fPIC EthernetConnector.cc
>>>
>>> cc -shared -o libNetworkInterface.so -fPIC NetworkInterface.cc
>>>
>>> I then copied them to the location of my gnuradio .so files
>>>
>>> ----------
>>>
>>>
>>> Unfortunately, this still hasn't solved the problem. Does anyone know a
>>> solution to this problem?
>>>
>>>
>>> Tommy James Tracy II
>>>
>>> Ph.D Student
>>>
>>> High Performance Low Power Lab
>>>
>>> University of Virginia
>>>
>>> Phone: 913-775-2241
>>>
>>>
>>
>>> _______________________________________________
>>> Discuss-gnuradio mailing list
>>> Discuss-gnuradio@gnu.org
>>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
>>
>> --
>> Karlsruhe Institute of Technology (KIT)
>> Communications Engineering Lab (CEL)
>>
>> Dipl.-Ing. Martin Braun
>> Research Associate
>>
>> Kaiserstraße 12
>> Building 05.01
>> 76131 Karlsruhe
>>
>> Phone: +49 721 608-43790
>> Fax: +49 721 608-46071
>> www.cel.kit.edu
>>
>> KIT -- University of the State of Baden-Württemberg and
>> National Laboratory of the Helmholtz Association
>>
>> _______________________________________________
>> Discuss-gnuradio mailing list
>> Discuss-gnuradio@gnu.org
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
>
>
>
> --
> Tom
> GRCon13 Oct. 1 - 4
> http://www.trondeau.com/grcon13
>
> _______________________________________________
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
