[mini-1235]

Problem

On macOS, vendored Ogre is installed in opt/rviz_ogre_vendor/lib but identifies itself as @rpath/libOgreMain_rviz.1.12.10.dylib. Any binary without an RPATH to that private directory fails to load. rviz2 has one, which hides the issue. moveit_setup_assistant does not:

dyld: Library not loaded: @rpath/libOgreMain_rviz.1.12.10.dylib

rviz_ogre_vendor is the only vendor package here with libraries in opt/; the gz_* vendors use conda-forge packages in lib/.

Change

• Add ros2-rviz-ogre-vendor.osx.patch to Jazzy, Lyrical and Rolling. It sets CMAKE_INSTALL_NAME_DIR and CMAKE_MACOSX_RPATH=OFF for Ogre, so consumers record the absolute path. Packaging rewrites it to the install prefix.
• Bump rviz_ogre_vendor and the packages that link it. The list comes from scanning the otool -L output of released osx-arm64 packages, because metadata is not reliable here: moveit_ros_visualization only declares rviz2. The bumps rebuild these packages on every platform, though the patch only applies on macOS.

Consumers not rebuilt keep the old @rpath reference, so they behave as they do today.

Validation

• check-patches for ros2-rviz-ogre-vendor and pixi run rs check pass.
• Local osx-arm64 builds of rviz-ogre-vendor, rviz-rendering, rviz-common, rviz-default-plugins and moveit-ros-visualization, on all three distros.
• Installed at a new prefix: Ogre references point to that prefix.
• ros2 launch moveit_setup_assistant setup_assistant.launch.py crashes with released Jazzy packages. With this change it opens on Jazzy, Lyrical and Rolling, confirmed by capturing the app window. A Lyrical/Rolling run without this change was not repeated.
• rviz2 stays running on Lyrical and Rolling.

Not tested: osx-64, the other bumped packages, loading a robot in Setup Assistant, the 3D view, or rviz2 on Jazzy with this change.

Screenshots

moveit_setup_assistant with this change:

Jazzy

Lyrical

Rolling

This description was AI-generated by Claude Opus 5.5.

🤖 Generated with Claude Code

[mini-1235]

Ah sorry I think this only partially fixes the issue, let me dig into it

xref: https://discord.com/channels/1082332781146800168/1566567033590775949/1566567033590775949

[mini-1235]

@traversaro @Tobias-Fischer I believe this fixes the issue reported in discord, but I am not sure if this is the cleanest solution. Could you please take a look?

[Tobias-Fischer]

That's one for our cmake guru @traversaro ..

[traversaro]

Sorry, I was ignoring this as it was still in draft.

[traversaro]

I was not aware of this problem, but this solution indeed make sense in conda where the harcoded absoluted install path is relocated automated by the conda install tools, but I am not sure if it make sense as a general fix. fyi @idesign0 any opinion on this, especially about a fix that we can upstream that could make sense for both conda/robostack and homebrew? My agent found the code in https://github.com/idesign0/ros2_macOS/blob/jazzy-new/ci/deploy/package_tree.py#L444-L464, not sure if it is related or if you have any experience in running moveit_setup_assistant on macOS.

[mini-1235]

Sorry, I was ignoring this as it was still in draft.

Oh sorry, I should have hit the button.

about a fix that we can upstream that could make sense for both conda/robostack and homebrew?

I think ros2/rviz#1683 should help moving forward if it lands in Makoa, but this will likely still be an issue for older distros. I also think my patch here is probably not the best solution to upstream, but I don't have a better alternative at the moment.

[traversaro]

I also think my patch here is probably not the best solution to upstream, but I don't have a better alternative at the moment.

Sure! Anyhow, this is good to merge for me, everything else was just related discussions.

[traversaro]

I think ros2/rviz#1683 should help moving forward if it lands in Makoa,

Thanks for linking that, I did not noticed that. We looked to that in the past but was a bit of a can of worms due to the different ogre requirements between gz-rendering and rviz (and also the different ogre version available in different distros), but hopefully now with our agentic friends it may be more manageable, but I guess an important prerequisite would be anyhow conda-forge/gz-rendering-feedstock#47 .

[idesign0]

I was not aware of this problem, but this solution indeed make sense in conda where the harcoded absoluted install path is relocated automated by the conda install tools, but I am not sure if it make sense as a general fix. fyi @idesign0 any opinion on this, especially about a fix that we can upstream that could make sense for both conda/robostack and homebrew? My agent found the code in https://github.com/idesign0/ros2_macOS/blob/jazzy-new/ci/deploy/package_tree.py#L444-L464, not sure if it is related or if you have any experience in running moveit_setup_assistant on macOS.

@traversaro Your agent found the right spot — we hit this and handled it from the other end.

We leave Ogre's install name as @rpath/... and fix the consumers: at packaging time we walk each opt/*/lib, and anything whose otool -L references a dylib living there gets that absolute dir added as an RPATH. package_tree.py#L444-L464.

On a general fix for both, though — I don't have one. Ours is a post-build pass over a packaged tree, so it does nothing for a from-source build; yours relies on conda relocating the baked-in path, which Homebrew doesn't do. The assumptions differ on each side, and I can't see one fix that covers both short of rviz not vendoring Ogre at all.

Caveat: I haven't run moveit_setup_assistant on macOS yet. Our moveit and rviz domains build clean, but I have no runtime validation of that app — your screenshots are better evidence than anything I can show.

+1 on ros2/rviz#1683 as the real cure. Happy to test on the Homebrew side if it moves.