Repository navigation
AppImage (all distros) missing RMW provider .so — dlopen'd libs not captured by ldd bundling #10
Description
Activity
Fixed in #15, released in 0.10.0.
Your diagnosis was exactly right:
lddonly reports link-time dependencies, so the RMW providers and therosidl_typesupport_*libraries — alldlopen'd — were never copied into the AppDir.What changed:
- Bundling moved out of the workflow YAML into
packaging/make_appdir.sh, so it can be run and tested locally rather than only in CI. - Both RMW providers (
rmw_fastrtps_cpp,rmw_cyclonedds_cpp) and everyrosidl_typesupport_*flavour are now copied, along with their transitive dependencies. The dependency walk runs against the original files, because a copy's$ORIGINrpath no longer resolves — that silently truncated the closure on the first attempt. RMW_IMPLEMENTATIONis deliberately not pinned inAppRun, contrary to the suggestion in your report: the vendor has to match the user's other nodes, so forcing one would break anyone running CycloneDDS. Shipping both providers and leaving the variable to the environment covers both cases.
Verified with your exact repro — a clean
ubuntu:24.04container with no ROS — on the CI-built artifact, not just a local build. Also checked end-to-end: host publishers, bridge in the container, three topics streaming at 20 Hz, withRMW_IMPLEMENTATIONunset and set tormw_cyclonedds_cpp.One caveat worth stating explicitly: the AppImage still isn't self-sufficient for custom message types.
AMENT_PREFIX_PATHappends the bundle after the user's entries, so a sourced workspace keeps priority; the bundled definitions are only a fallback for common types. A topic whose type isn't resolvable is skipped with an error rather than taking the bridge down.Thanks for the precise report — the
find squashfs-rootoutput made this quick to confirm.- Bundling moved out of the workflow YAML into
Summary
All three prebuilt AppImages from release 0.9.0 fail to start on a clean machine (no system ROS):
Tested with both
pj_bridge_ros2-humble-x86_64.AppImageandpj_bridge_ros2-jazzy-x86_64.AppImage(kilted uses the same workflow). Ubuntu 24.04.Reproduce
chmod +x pj_bridge_ros2-jazzy-x86_64.AppImage env -i HOME=$HOME PATH=/usr/bin:/bin ./pj_bridge_ros2-jazzy-x86_64.AppImage --ros-args -p port:=9090Root cause
In
.github/workflows/appimage.yaml, conda deps are bundled vialdd:The RMW provider libraries (
librmw_fastrtps_cpp.so,librmw_cyclonedds_cpp.so, …) are loaded bydlopenat runtime, so they don't appear inlddoutput and are never copied. The image ends up withlibrmw_implementation.so(linked) and the ament_index markers (copied viashare/ament_index), but no provider.so— sormw_implementationfinds the index entry, fails to dlopen the provider, and aborts.Confirming on the extracted image:
Suggested fix
Explicitly copy the RMW provider
.so(s) intoAppDir/usr/lib/and pin one inAppRun, e.g.:and in
AppRun:export RMW_IMPLEMENTATION=rmw_fastrtps_cppWorkaround (for users)
.deb(ros-jazzy-pj-bridge_0.9.0-0noble_amd64.deb) works — it links against system/opt/ros/<distro>and uses the system RMW provider.pixi global install pj-bridge-ros2-*also works (conda env ships the provider).