discuss-gnuradio
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] Building an OOT modules with an In Tree Dependenc


From: Tom Rondeau
Subject: Re: [Discuss-gnuradio] Building an OOT modules with an In Tree Dependency
Date: Fri, 31 Jul 2015 10:26:34 -0400

On Thu, Jul 30, 2015 at 5:26 PM, Valenta, Chris R. <address@hidden> wrote:

I’m trying to make an out of tree module based on blocks::file_sink that has some additional functionality I need. Right now, I’ve built it OOT, but an having trouble getting it to work. The code (file_sink_impl.cc, file_sink_impl.h, and file_sink.h à actual names are different so there are no conflicts) are all identical to the ones in tree. I used gr-modtool to create the OOT modules with this block and it makes and installs fine. However, when I try to use it, I get the following error:

 

AttributeError: ‘file_sink_sptr’ object has no attribute ‘set_unbuffered’

 

What I think is happening here is that the OOT version of my code isn’t linking to the file_sink_base in gnuradio-blocks to inherit this function. Browsing previous mail lists, Marcus Muller noted in the thread ‘ [Discuss-gnuradio] Out of Tree linker error... libgnuradio-MYMOD.so:‘ that the problem might be in my cmake files. He referenced gr-specest as an example which uses in tree modules. I compared the cmakelists.txt in gr-specest to the OOT module directory and in the OOT/lib directory and added the BLOCKS references in the appropriate places. However, this still hasn’t solved the problems.

Are there any other steps necessary to make and install an OOT modules with in tree dependencies?

 

All of this is running on Ubuntu 14.04LTS with gnuradio 3.7.7.1

The first thing that comes to mind when we see this is that you haven't added all of the public functions of your block to the public header file (file_sink.h), but you say that's identical. Still probably worth checking on that file to make sure.

Have you looked at your swig directory's .i file? That needs to properly reference your block to export it into Python. It seems like this is ok since you're getting as far as to see the error on the method, not the block. Again, though, something to check.

So this is just you replicating the file sink blocks completely? You aren't trying to inherit from them or use them internally, are you? That might cause other issues.

Tom


reply via email to

[Prev in Thread] Current Thread [Next in Thread]