ROS libraries on macOS leave it to the application to load a Python shared library

[EliaCereda]

Without this change, Coppelia fails to dlopen the libsimROS2.dylib because it needs Python symbols but does load libpython itself.

Error in Coppelia log window

plugin simROS2: Cannot load library /Applications/coppeliaSim.app/Contents/MacOS/libsimROS2.dylib: (dlopen(/Applications/coppeliaSim.app/Contents/MacOS/libsimROS2.dylib, 0x0005): symbol not found in flat namespace '_PyExc_RuntimeError')

[jeguzzi]

Note: this is not a bug of the CoppeliaSim plugin but an hack to force loading the python shared lib, which is needed to overcome a problem when using ROS installed with pixi+robostack on macOS.

[traversaro]

Note: this is not a bug of the CoppeliaSim plugin but an hack to force loading the python shared lib, which is needed to overcome a problem when using ROS installed with pixi+robostack on macOS.

Just to clarify (as I spent some time to fully grasp the problem myself in other case) the reason for that is that conda-forge Python interpreter statically links the libpython library, and so Python extensions on conda-forge (or in related distros, like robostack) do not link the libpython libraries to avoid crashes at runtime (as far as I know, just on macOS).

[traversaro]

xref to the related discussion in astral-sh/python-build-standalone#540 and ros2/rclpy#1305 for a related ROS 2 upstream fix.