gr-osmosdr python failure

I tried to file a bug at the gitea, but it seems not to allow
registration.

In pkgsrc, we have a ham/gr-osmosdr package which is pretty
straightforward. Recently we got a report that while it builds,
importing the python module fails, unless one uses gcc12 (instead of
10). The README doesn't document a C++ language variant, but CMakeFile
is clear that it's c++11, which gcc10 supports just fine.

The symptom is:

> python3.12
Python 3.12.10 (main, May 9 2025, 12:01:51) [GCC 10.5.0] on netbsd10
Type "help", "copyright", "credits" or "license" for more information.
>>> import osmosdr
Traceback (most recent call last):
File "/usr/pkg/lib/python3.12/site-packages/osmosdr/__init__.py", line 17, in <module>
from .osmosdr_python import *
ImportError: generic_type: type "sink" referenced unknown base type "gr::hier_block2"

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "/usr/pkg/lib/python3.12/site-packages/osmosdr/__init__.py", line 21, in <module>
from .osmosdr_python import *
ImportError: generic_type: type "sink" referenced unknown base type "gr::hier_block2"


So, my questions are:

is C++11 really the required standard?

is there some new code assuming a newer --std, and this only works
with gcc12 because it defaults to newer?

gnuradio itself seems to require c++20. Is this "gnuradio header
files need to be processed in c++20 mode, but they don't error if
processed in c++11 mode"?

gnuradio itself seems to require c++20. Is this "C++ ABI is a mess
and using headers that are valid c++11 with a c++11 compiler, won't
interwork with code built in c++20 mode"?

something else?