I’ve spent some time recently attempting to update gr-specest to 3.7,
and I’ve run into a linker issue that’s a bit out of my depth, any
suggestions would be helpful.
Remove FindGnuradioCore.cmake and FindGruel.cmake, replaced with
FindGnuradioRuntime.cmake
that I pulled out of
gr-utils/python/modtool/gr-newmod/cmake/Modules/FindGnuradioRuntime.cmake
Remove all GRUEL_ references and replace GNURADIO_CORE variables
with GNURADIO_RUNTIME_
Update #include<gruel/attributes.h> to <gnuradio/attributes.h>
Changed file structure:
from gr-specest/include/specest-blockname.h to
gr-specest/include/specest/blockname.h
from gr-specest/lib/specest-blockname.cc to
gr-specest/lib/blockname.cc
(actually, I think that there was some significant changes that
should have been done to split
blockname.cc into blockname_impl.h and blockname_impl.cc but I’m
actually confused by all the
blockname_impl.h that are placed under include/specest, and I’m
not entirely sure that the
split didn’t already happen under 3.6)
Updated gnuradio header files e.g. ‘#include <gr_sync_block.h>’ to
‘#include <gnuradio/sync_block.h’
Updated gnuradio classes and functions to new namespace, e.g.
gr_make_io_signature() to gr::io_signature::make()
Current status of the effort:
Complilation errors caused by the need for above updates now worked
out and the files compile without error.
Build currently broken, stuck at linker errors:
…
[ 52%] Built target gnuradio-specest
Linking CXX executable qa_arburg_impl
libgnuradio-specest.so: undefined reference to fftwf_free' libgnuradio-specest.so: undefined reference to fftwf_malloc’
…
Will be looking into the FindGnuradioRuntime.cmake file I lifted
from gr-utils
Would love suggestions on how to debug this, “nm” and “ldd” show
issues but not root causes…
Future work not yet started:
updating the gr-specest namespace to the new format
adding new blocks: cross-correlation, normalization, running sum,
etc
I’ve posted all my code at GitHub - dfxx/gr-specest: A module adding spectral estimation routines to GNU Radio.. Any
help tracking down the root cause of the linker errors would be
greatly appreciated. I have the feeling that it might be in the cmake
configuration, and I feel somewhat like a bull in a china shop when I
start poking around in cmake. Lots of delicate looking code in there.
that I pulled out of
blockname.cc into blockname_impl.h and blockname_impl.cc but I’m
Complilation errors caused by the need for above updates now worked
Would love suggestions on how to debug this, “nm” and “ldd” show
start poking around in cmake. Lots of delicate looking code in there.
You’ll (probably) need to link against fftw. I think you need to add
the FFT3 library to target_link_libraries in the lib/CMakeLists.txt
file. There was a change in policy for linking recently that’s
affected things like this.
Thanks for the help, I’m now compiling without errors. I generated a
new skeleton module with gr_modtool and through diffing the CMakeLists
files between the generated and the currently used ones I was able to
track down the last of the include/linking errors. Worked much better
than attempting to track them down in the in-tree modules.
Am I missing a gnuradio link command that I should know about?
Thanks,
Jared
Jared,
Because it looks like it’s trying to use blocks out of
gnuradio-filter, gnuradio-fft, and gnuradio-blocks, I think you’ll
need to link against all of those libraries, too. Using the
GnuradioConfig cmake, you can set all of this up with:
You’ll then have access to the libraries using the following variables:
GNURADIO_RUNTIME_LIBRARIES
GNURADIO_BLOCKS_LIBRARIES
GNURADIO_FILTER_LIBRARIES
GNURADIO_FFT_LIBRARIES
Similarly, you’ll have GNURADIO__INCLUDE_DIRS so you can set
your ‘include_directories’ in cmake.
I gave it a good lube job and it mostly works now… Still in need
of
the full tune up to change everything over to the new namespace. I’m
still
seeing some issues, like did the pad_vector function ever work? It
seems
to be missing some pieces. I slapped a GRC wrapper together, but it
doesn’t seem to actually pad things.
Jared
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.