Re: GRC 3.9.4.0 - module porting problem
Hi Ryan,
I eventually managed to port the working GRC code from 3.8.2.0 to 3.9.4.0 by
rebuilding the GRC with pybind11 2.5.0 installed and having replaced version
2.4.3, for all binding operations.
pygxxxml 2.2.1 was also retained.
The porting guide document after re-read is entirely correct about
compatibility.
Thanks again,
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_gr::basic_block,
std::shared_ptr>(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
Re: GRC 3.9.4.0 - module porting problem
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_gr::basic_block,
std::shared_ptr>(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
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_>(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
GRC 3.9.4.0 - module porting problem
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_>(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
