PYTHON_SOABI returns a host version of SOABI while cross-compiling

[razr]

Bug report

Required Info:

• Operating System:
  • host: Ubuntu 18.04
  • target: VxWorks 7
• Installation type:
  • source compilation
• Version or commit hash:
  • dashing release
• DDS implementation:
  • N/A
• Client library (if applicable):
  • N/A

Steps to reproduce issue

While cross-compiling the ROS2 dashing release for VxWorks and encounter the following problem FindPythonExtra.cmake gives back a host PYTHON_SOABI instead of a target one. It runs get_config_var('SOABI') using native python "from sysconfig import get_config_var" "print(get_config_var('SOABI'))"

After that all python ROS2 modules are built with the host extension and not loadable on the target system. build: _rclpy.cpython-38-x86_64-linux-gnu.so expected: _rclpy.cpython-38-vxworks.so

Expected behavior

It should give back a target SOABI, not the host one. Probably a bit more sophisticated check shall be implemented, e.g. run a target version of python3-config --extension-suffix

Actual behavior

always returns the host python SOABI version

Additional information

It is possible to define -DPYTHON_SOABI="my SOABI" to workaround it.

[hidmic]

@razr thanks for reporting ! Would you be willing to submit a fix for this issue?

[razr]

Yes, I will. However, I can provide it at the moment against the ROS2 dashing release and I can only test it for the VxWorks cross and Ubuntu 18.04 native builds. Please let me know if it is ok with you.

[hidmic]

Hmm, to patch release an LTS distro and hope we can fast-forward those changes to master at some point in the future isn't ideal. But I understand the situation. What do you think @nuclearsandwich ?

[nuclearsandwich]

Thanks for being willing to put in the work @razr! I definitely don't want to turn away your contributions but I also want to make sure that any work you do has a high chance of successfully being merged.

I'd much rather see a fix come in targeting the latest development branch with intent to backport. I'm also not sure if an explicit CMake define is the best way to fix the issue. Have you checked https://github.com/ros-tooling/cross_compile to see if they've solved this issue? If not it might be worth opening an issue there or transferring this one as the maintainers of that repository may have the resources to test on master before backporting any changes.

[razr]

No, I didn't look there but without fixing this part whatever they do most probably does not help. I do agree it is better to fix it in the master branch. I have just started with master and didn't hit this problem yet. We can just wait a bit :). I don't think it is a critical issue and a workaround exists.

Here https://index.ros.org/doc/ros2/Tutorials/Cross-compilation/ stated that PYTHON_SOABI shall be set. And here https://answers.ros.org/question/329161/rclpy-fails-to-run-on-arm64-after-cross-compilation/ someone complains that cross-compilation does not work due to exactly the reason I have described.