rosidl_generator_py_generate_interfaces: link Python3::Module instead of Python3::Python#253
rosidl_generator_py_generate_interfaces: link Python3::Module instead of Python3::Python#253traversaro wants to merge 1 commit intoros2:rollingfrom
Conversation
… of Python3::Python This is required to avoid segmentation faults on macOS with a statically compiled Python interpreter. Signed-off-by: Silvio Traversaro <silvio@traversaro.it>
fujitatomoya
left a comment
There was a problem hiding this comment.
i think this is a right thing to do.
- the code is building extension modules, so Python3::Module is the correct target.
- Python3::Module avoids this by using the correct linker flags (on macOS, it uses -undefined dynamic_lookup instead of linking libpython directly).
- this actually aligns with CMake best practices as suggested.
lgtm with green CI.
|
Pulls: #253 |
|
This PR causes undefined references when building interface packages. |
|
I guess |
Unless you are embedding the Python interpreter, we should not link Python3::Python . I am not sure about the error but I suspect it is something else. |
|
That was a bit complex. It is not clear to me why, but the unique_identifier_msgs_s__rosidl_typesupport_c.cpython-312-x86_64-linux-gnu.so) but it also creates a SHARED library (that as far as I can see is only linked by the Python module) called ${rosidl_generate_interfaces_TARGET}__rosidl_generator_py (for example, libunique_identifier_msgs__rosidl_generator_py.so) in That would not be particularly problematic, as creating shared library with undefined symbols is common practice in Linux. The problem is that then a completely different cmake extension |
|
I opened ros2-rust/rosidl_rust#22, I guess we do not want to merge this PR until ros2-rust/rosidl_rust#22 is merged and released. |
Description
When linking a Python loadable module (or a shared library that will be linked by a Python loadable module), CMake suggest to link
Python3::Moduleinstead ofPython3::Python, see https://cmake.org/cmake/help/latest/module/FindPython.html. In particular,Python3::Pythonis described as:while
Python3::Moduleis described as:Why is this necessary? There is not a big difference on any platform, except on macOS when using a Python interpreter that statically link
libpython. In that case, linking toPython3::Moduleensure that there are no segfaults when the corresponding Python module is loaded in the Python interpreter.See some related issues on this:
pythonexecutable tolibpythonand disable the shared library astral-sh/python-build-standalone#540 (comment)SHAREDfrompybind11_add_modulerclpy#1305Fixes # (issue)
Is this user-facing behavior change?
No, it is not a user-facing behaviour change.
Did you use Generative AI?
No.
Additional Information
This is one of the long standing patches that we carry on in RoboStack, I am not sure why we never upstreamed it.