Problem with undefined symbol in new block created by gr_modtool in 3.7.2

GNU Radio
#1

Hello all,

I am dealing with the problem of undefined symbol when trying to execute
a
python script for testing my new custom block created in GNU Radio
3.7.2.
I used gr_modtool for creating the new block and also followed the
instructions posted at

http://gnuradio.org/redmine/projects/gnuradio/wiki/OutOfTreeModulesConfig

for correctly configuring it but the problem still holds.

Any ideas?

Thanks,
-George

#2

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Hi George,
This is a little unspecific. Most probably you have a problem similar to
the fftw- related problem of activecat, but that’s only guessing…
Please heed
http://gnuradio.org/redmine/projects/gnuradio/wiki/ReportingErrors when
reporting errors.
Greetings,
Marcus

On March 5, 2014 8:57:46 PM CET, George S.
[email protected] wrote:

Discuss-gnuradio mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Sent from my Android device with K-9 Mail. Please excuse my brevity.
-----BEGIN PGP SIGNATURE-----
Version: APG v1.0.9

iQFABAEBCAAqBQJTF4c7IxxNYXJjdXMgTfxsbGVyIDxtYXJjdXNAaG9zdGFsaWEu
ZGU+AAoJEBKNLRrpJvfojQoH/2a609iWLTsywtozQ+FcZkuQT6uCy13vX3n4b5k3
rTvy9QP3uHuHQkiRZHDbZoJ+mZ9kFOf6NeG20RGdf8i4yCB1AZ8F7uvvdi7CebXT
sRQxoQE+8Vz5VS+faAStAOK3+tArdRGZOU2v3gTYXGCvATaeM3A+rxsNQ7LKPwM8
sI5KZ3xgvgikkObbFuo00MOaLA7tHzMttXxWjU5riXann1l1eOyGIzM1j0XO1gAD
imofs0DfXHB4cE0Gi43E1gjjeqEW034dLZAS7w/c/Gq85Z0Ni+z1a35kS5UYvYhQ
ndeEMqrLQv4ghCRnHR93ob+8YRlqMedVjDDeKQdjEh0D2jY=
=27ny
-----END PGP SIGNATURE-----

#3

What is the “undefined symbol”? This could be something not linked
properly inside the CMake files.

Michael

On Wed, Mar 5, 2014 at 11:57 AM, George S. <

#4

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.

Sean

#5

Thanks everyone.
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
/include/nameofBlock .

Thanks,
-George

George S.

#6

Ah, nevermind about the wiki edit. The use of pure virtual functions is
already discussed in
http://gnuradio.org/redmine/projects/gnuradio/wiki/BlocksCodingGuide .
Still, the gr_modtool addition may be useful.

#7

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
impl.cc file).

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
good, though.
I’ll think about this.

M