[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: GRC 3.9.4.0 - module porting problem
From: |
David Taylor (manx.net) |
Subject: |
Re: GRC 3.9.4.0 - module porting problem |
Date: |
Sat, 5 Mar 2022 13:26:08 -0000 |
Hi Ryan,
Thanks for the prompt reply.
The C++ compiler version used to first build GRC 3.9.4.0 and then compile
the OOT GRC block code is (Ubuntu 9.3.0-17ubuntu1~20.04) 9.3.0
I will check the same on the computer being used for GRC 3.8.2.0 use shortly
and critically look at the cmake output for clues in discrepancy.
I have found in the past that an incremental inclusion of the C++ source
code through the build process helps to identify the cause of the import
failure. - He says, stating the obvious!!
All the best,
David
-----Original Message-----
From: Ryan Volz
Sent: Friday, March 4, 2022 10:22 PM
To: discuss-gnuradio@gnu.org
Subject: Re: GRC 3.9.4.0 - module porting problem
Hi David,
If it works somewhere with GR 3.9, then it's not a porting problem and
you've done everything right there.
I've recently discovered for myself that an OOT's Python bindings will throw
this error when even the compiler version is different between building GNU
Radio and the OOT, in addition to needing the same pybind11 version. Is
there a chance this is what you're seeing? Run "gnuradio-config-info --cxx"
to see what compiler GNU Radio was built with, and compare with what you're
using to build the OOT module.
(For me, this has happened in building OOT modules for conda-forge when the
conda-forge project recently started using GCC 10 instead of GCC 9. Modules
built with GCC 10 were not compatible with a GNU Radio built with GCC 9. It
turns out that they actually would be compatible, and pybind11 is being too
careful, but I would have had to know that ahead of time to avoid the
problem. So for now I have to stick to the same compiler version for
everything.)
Cheers,
Ryan
On 3/4/22 3:35 PM, David Taylor (manx.net) wrote:
Hi All,
I am sorry to be covering what is old ground, but I am having a final
loading issue with an otherwise working OOT block.
The block works under GRC 3.8.2.0 and GRC 3.9.4.0 was built on another
computer without issue.
ImportError:generic_type "channel_signal_generator_cc" referenced unknown
base type "gr::sync_block"
Ubuntu 20.04
python 3.8
pybind11 2.5.0 – replacing 2.4.3 in accordance with the latest 3.9 Module
Porting Guide (28 Feb 2022)
pygccxml 2.2.1
Additional libraries are found at cmake and during the build. The block
imports correctly with no changes necessary to the .yml file.
The new block was created using 3.9 gr_modtool and code dropped in, noting
the changes to shared_ptr use.
The block was sync_block type at definition, with the virtual block
classes noted in the porting guide automatically inserted during bind in
/python/bindings/....
void bind_channel_signal_generator_cc(py::module& m)
{
using channel_signal_generator_cc =
::gr::oot::channel_signal_generator_cc;
py::class_<channel_signal_generator_cc, gr::sync_block, gr::block,
gr::basic_block,
std::shared_ptr<channel_signal_generator_cc>>(m,
"channel_signal_generator_cc", D(channel_signal_generator_cc))
.def(py::init(&channel_signal_generator_cc::make),
py::arg("samp_rate"),
py::arg("length_chips"),
py::arg("duration_sec"),
py::arg("filename"),
py::arg("CN0_dB"),
D(channel_signal_generator_cc,make)
)
Any comments would be welcome.
Many thanks,
David GD4FMB