Hello,
I’m working on a C++ block which accepts a pointer to a uhd sink and
calls the sink’s set_center_frequency method to change to a new
frequency. Set_center_frequency requires input in the form of a
uhd::tune_request_t and returns a uhd::tune_result_t. As a bit of
background, I generated an out of tree module with gr-modtool.py. It
contains this block as well as two other blocks. The other blocks can be
used in GRC but this on cannot as it requires a pointer, so I disabled
the installation of its xml file in grc/CMakeLists.txt and will be using
it exclusively through c++. The issue that I am having seems to be in
accessing the libraries for UHD.
//My call to set_center_frequency, where private_UHD_Sink is a pointer
to a UHD Sink and private_freqs is a pointer to the first member of an
array and current_freq sets the index of the array
uhd::tune_result_t result_sink =
private_UHD_Sink->set_center_freq(uhd::tune_request_t(*(private_freqs +
current_freq)));
I first compiled my flowgraph without #including <tune_result.hpp> and
<tune_request.hpp> in my source file. Surprisingly, things compile just
fine without the two files. However, a c++ flowgraph which tries to use
the block gives a nondescript error (“expected primary-expression before
(”) on the line which instantiates my block. Using one of the other
blocks (which share the same module) in GRC returns “ImportError:
/usr/local/lib/libgnuradio-DL_Hitemp_Blocks.so: undefined symbol:
_ZN3uhd14tune_request_tC1Ed”.
I then thought that I would try to include the two files mentioned
above, and of course it refused to compile because it could not find the
files. I looked at the CMakeLists.txt file included with the tag demo
c++ example included in gnuradio and decided to add
include_directories(${UHD_INCLUDE_DIRS}) and
link_directories(${UHD_LIBRARY_DIRS}) to my CMakeLists.txt file in my
src directory. The issue seems to be that many of the cmake directory
variables on my system were not set properly. Adding “MESSAGE(STATUS,
“GR include path: ${GNURADIO_CORE_INCLUDE_DIRS}”)” to my CMakeLists.txt
file produces “STATUS,GR include path: /usr/local/include/gnuradio” but
this is the only GNUradio related cmake variable I have found that seems
to have been set properly. Adding “MESSAGE(STATUS, “UHD include path:
${UHD_INCLUDE_DIRS}”) MESSAGE(STATUS, “UHD include path:
${UHD_LIBRARY_DIRS}”)” produces "STATUS,UHD include path: STATUS,UHD
include path: ". I was able to get the source to compile by setting the
UHD include path absolutely (added
“include_directories(/usr/local/include/uhd/types)” to my CMakeLists.txt
file - but I can’t seem to find the UHD_Library_Directory so I cannot
try setting it absolutely. The program now compiles, but the same error
is produced in GRC as well as in the c++ flowgraph. I am wondering if
anyone has any idea how I could go about including the appropriate UHD
libraries or what else could be causing these errors? Thanks ahead of
time!
accessing the libraries for UHD.
fine without the two files. However, a c++ flowgraph which tries to use
include_directories(${UHD_INCLUDE_DIRS}) and
UHD include path absolutely (added
“include_directories(/usr/local/include/uhd/types)” to my CMakeLists.txt
file - but I can’t seem to find the UHD_Library_Directory so I cannot
try setting it absolutely. The program now compiles, but the same error
is produced in GRC as well as in the c++ flowgraph. I am wondering if
anyone has any idea how I could go about including the appropriate UHD
libraries or what else could be causing these errors? Thanks ahead of time!
Thanks for the reply Josh! That definitely seems to have solved part of
my problem. I did still have to include the ${UHD_INCLUDE_DIRS} directly
(added include_directories(/usr/local/include/uhd/types) to my
CMakeLIsts.txt). If you have a suggestion that might make this
unnecessary I will give it a shot but this I can live with. I am now
able to compile the Module containing my Block successfully. However,
when I run another block from the module or try to compile my C++
flowgraphs I get the same errors. Any thoughts? I can’t rule out an
error in my code but this wouldn’t explain the GRC error.
It occurred to me that I may have edited a file which could have caused
the error in GRC. When I tried to compile my module, a class called
Python_wrap, which appears to be related to swig, returned an error. As
I intend to use this function only at the C++ level since it requires
pointers to UHD Source/Sink objects, I assumed swig was unnecessary and
removed all occurrences of the header for my block from
/source/swig/(module name)swig.i . This allowed the module to compile
with no issues but I’m wondering if it could have caused the error in
GRC? While I find it unlikely as swig should not be needed in C++, could
it have caused the error I observed in my C++ flowgraph? If this may be
responsible for these errors, how can I handle this issue? Thanks!
I’ve been thinking about this issue and I have a feeling that the
problem is that swig may not support my use of pointers as function
parameters. My block accepts a boost::shared_ptr<uhd_usrp_sink> and a
boost::shared_ptr<uhd_usrp_source> as parameters. Disabling swig as I
did before seems to have created other issues. Is there any way that I
can either fix the swig error or disable swig altogether for this block
and just install and link for c++, and not python, flowgraphs?
Thanks for the reply Josh! I should have been more specific. The link to
the compile error http://pastebin.com/cVHrjN0kwas in the previous
message which I had linked to. I can get passed this error if I remove
all references to the problem header from
//src/swig/<Module_Name>_swig.i , but perhaps this causes the problems I
mentioned in my first post http://lists.gnu.org/archive/html/discuss-gnuradio/2012-07/msg00222.html
(second-to-last paragraph, although I have since been able to include
include both files thanks to your last suggestion. The problems remain
though.)? /Will read up on template directives. Was wondering if swig is
even necessary to use my block in C++ flowgraphs?
Thanks for the reply Josh! I should have been more specific. The link to
the compile error http://pastebin.com/cVHrjN0kwas in the previous
message which I had linked to. I can get passed this error if I remove
all references to the problem header from
//src/swig/<Module_Name>_swig.i , but perhaps this causes the problems I
mentioned in my first post
Looks like its missing an include for the
DL_Hitemp_Blocks_Frequency_Changer interface.
Careful, there are includes for compiling the wrapper and there are
includes for exporting interfaces to swig %include vs #include. Here is
a good example, see how the block includes appear 2x in the file with
different directives: http://gnuradio.org/cgit/gnuradio.git/tree/gr-uhd/swig/uhd_swig.i#n40
http://lists.gnu.org/archive/html/discuss-gnuradio/2012-07/msg00222.html
(second-to-last paragraph, although I have since been able to include
include both files thanks to your last suggestion. The problems remain
though.)? /Will read up on template directives. Was wondering if swig is
even necessary to use my block in C++ flowgraphs?
swig is only for python bindings. All c++, then you dont need swig.
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.