Miklos,
Have you imported all of the gnuradio files into the swig .i file that you
are using within your OOT module? I recently went through this, and I had
to include a gnuradio header into my swig .i file as shown below; I'm not
entirely sure what the two include declarations are for, but I needed both
to work.
%{
#include "gnuradio/digital/constellation.h"
#include "<my OOT header>"
%}
%include "gnuradio/digital/constellation.h"
%include "<my OOT header>"
Also, make sure you include the appropriate .so file of any gnuradio object
you are using into the CMakeList.txt file, otherwise you may get a runtime
error as it cannot find the object you are referencing within gnuradio.
Michael Berman
On Fri, Oct 4, 2013 at 2:36 PM, Miklos Maroti <mmar...@math.u-szeged.hu>wrote:
> Hi Guys,
>
> I am trying to create a rational_sync_block class in an out of tree
> module, which is both an interpolator and decimator with a rational
> data rate. So I just wrote the class, almost exactly like how
> sync_interpolator is written. Then when I want to use this new base
> class in a derived real block named xxx_block in my out of tree
> module, then everything compiles, but the swig generation fails with
> an error message that xxx_block cannot be allocated because it is
> abstract type has an virtual work function. When I change the base
> type back to sync_interpolator, then swig is happy. I do not
> understand what is so special about gr::sync_interpolator, and why I
> cannot reproduce the sync_interpolator in a way that makes swig happy.
> Any ideas?
>
> Miklos
>
> _______________________________________________
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
