crosscompiling GNU Radio 3.9 (and 3.10?) uses host naming of library rather than target

[jmfriedt]

What happened?

Cross-compiling GNU Radio 3.9 to ARM aarch64 architecture using Buildroot and the
https://github.com/oscimp/oscimp_br2_external/blob/master/configs/raspberrypi4_64_gnuradio39_defconfig
configuration script leads to libraries (bindings?) named x86_64 which is the host architecture, and prevents GNU Radio from loading modules (e.g. import gnuradio in Python3 on the Raspberry Pi 4 target succeeds but from gnuradio import audio fails due to missing binding). Renaming all .so files including x86_64 (host architecture) to aarch64 (target architecture) ended up solving the problem. This sound very similar to pybind/pybind11#1330 concluding with "now the pybind takes the correct python directory but still the architecture of the generated .so file is x86_64" but no solution is provided. This issue is also valid for OOT module, e.g. when cross-compiling https://github.com/jmfriedt/gr-rpitx the resulting .so file must be renamed from the host to target architecture.

System Information

Buildroot 2021.11 with the configuration file mentioned in the bug report

GNU Radio Version

3.9 (maint-3.9)

Specific Version

0.0.0.0

Steps to Reproduce the Problem

Select GNU Radio 3.9 in the Buildroot configuration. After make and running the dd-ed on the RPi4, running in Python3
from gnuradio import audio
will fail due to misnamed library (binding) .so. Renaming (mv) or linking (ln -s) to the same library name but replacing x86_64 with aarch64 solves the issue.

Relevant log output

No response

[drmpeg]

This was discussed on Matrix/IRC, but I'm going to document it here. The ABI string comes from pybind11. Here are the details.

A special function pybind11_add_module() in gnuradio/cmake/Modules/GrPybind.cmake is used to create the Python binding libraries.

https://github.com/gnuradio/gnuradio/blob/master/cmake/Modules/GrPybind.cmake#L9

https://github.com/gnuradio/gnuradio/blob/master/cmake/Modules/GrPybind.cmake#L120

https://github.com/gnuradio/gnuradio/blob/master/cmake/Modules/GrPybind.cmake#L261

This function is in /usr/lib/cmake/pybind11/pybind11Tools.cmake. Within that function, a call to set_target_properties() is made.

set_target_properties(${target_name} PROPERTIES SUFFIX "${PYTHON_MODULE_EXTENSION}")

PYTHON_MODULE_EXTENSION is set to the ABI string. For example, .cpython-38-x86_64-linux-gnu.so or .cpython-39-riscv64-linux-gnu.so.

PYTHON_MODULE_EXTENSION is populated by this line in pybind11 (so it's a pybind11 issue, not a CMake issue).

https://github.com/pybind/pybind11/blob/master/tools/FindPythonLibsNew.cmake#L120

A possible workaround would be to override the target properties suffix. I tried the following in gnuradio/cmake/Modules/GrPybind.cmake after the pybind11_add_module() call and it works fine.

set_target_properties(${name}_python PROPERTIES SUFFIX ".so")

It may be better to add a conditional to retain functionality when not cross compiling.

if (CMAKE_CROSSCOMPILING)
  set_target_properties(${name}_python PROPERTIES SUFFIX ".so")```
endif(CMAKE_CROSSCOMPILING)

It may also be possible to find the correct ABI string for the cross compile, but I don't how how to do that.

[marcusmueller]

Untested, but my understanding:

pybind11's 918d4481a4f69c7a4cbb4282acbabd28e2433039 should fix that, if you define PYTHON_MODULE_EXTENSION before you pybind_add_module.

v2.10.0 does incorporate that. So, for cross-compiles, we'd need to bump the version requirement.

[marcusmueller]

@balister I think that might be a good heads up to give you: if you have a BB for GR that depends on pybind11, make sure it depends on Pybind11 >= v2.10.0.

[jmfriedt]

I have compiled GNU Radio in Buildroot git and Buildroot2024.02 (targeted to raspberrypi4_64) and both succeed without including target or host architecture in the library name, so I think this issue can be closed.