I am dealing with the problem of undefined symbol when trying to execute
python script for testing my new custom block created in GNU Radio
I used gr_modtool for creating the new block and also followed the
instructions posted at
for correctly configuring it but the problem still holds.
-----BEGIN PGP SIGNED MESSAGE-----
This is a little unspecific. Most probably you have a problem similar to
the fftw- related problem of activecat, but that’s only guessing…
On March 5, 2014 8:57:46 PM CET, George S.
[email protected] wrote:
Discuss-gnuradio mailing list
Sent from my Android device with K-9 Mail. Please excuse my brevity.
-----BEGIN PGP SIGNATURE-----
Version: APG v1.0.9
-----END PGP SIGNATURE-----
What is the “undefined symbol”? This could be something not linked
properly inside the CMake files.
On Wed, Mar 5, 2014 at 11:57 AM, George S. <
The first place I’d look is in your_block.h. Did you remember to declare
any public member functions to be pure virtual in that file, and then
declare your (non-virtual) functions in your_block_impl.h? If you forgot
to declare pure virtual functions, i.e., “virtual return_type
your_block(args_list) = 0;” in your_block.h, it will compile but you
will get the undefined symbol at runtime.
This probably a common pitfall and it might be worth making a note in
the wiki for OutOfTreeModules. I’ll add that.
Architects of gr_modtool… can you add an autogen comment in *.h files
reminding the user to declare pure virtual functions? I think users who
don’t deeply understand OO and particularly its C++ syntax would
benefit from this reminder. I think it’s a common paradigm to use other
examples to fill in the “guts” of gr_modtool generated C++ code, but
things like this are easy to miss.
In order to be more specific regarding the future readers of this post,
I am using Ubuntu 12.04 and GNU Radio v3.7.2.
I am using the embedded gr_modtool in order to create a custom signal
processing block from scratch.
My block does not use FFT.
Finally, the problem was solved by just ignoring the implementation
header file and only include the public header file in the
Ah, nevermind about the wiki edit. The use of pure virtual functions is
already discussed in
Still, the gr_modtool addition may be useful.
On 05.03.2014 22:44, Nowlan, Sean wrote:
Architects of gr_modtool… can you add an autogen comment in *.h
files reminding the user to declare pure virtual functions? I think
users who don’t deeply understand OO and particularly its C++ syntax
would benefit from this reminder. I think it’s a common paradigm to
use other examples to fill in the “guts” of gr_modtool generated C++
code, but things like this are easy to miss.
Disciples of gr_modtool…
When you create a block w/ modtool, it has zero public methods (except
for make(), which is arguably special, and gets auto-created in the
So if I put in a reminder, it will actually remind people before there’s
a reason to declare a function, which might confuse people.
Perhaps a more general instruction on how to add public methods would be
I’ll think about this.