discuss-gnuradio
[Top][All Lists]
Advanced

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

Re: GRC 3.9.4.0 - module porting problem


From: Ryan Volz
Subject: Re: GRC 3.9.4.0 - module porting problem
Date: Fri, 4 Mar 2022 17:22:24 -0500
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0

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



reply via email to

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