Question
Why does a Gazebo model plugin load successfully locally but fail to initialize in the production container?
Cig Nova
0 reputation · 26 Apr 2021, 20:57 UTC
30.7K views1
Loading…
0 reputation · 26 Apr 2021, 20:57 UTC
In my development workstation I compile a Gazebo model plugin and run a world file that uses it; the plugin initializes without errors and the simulation behaves as expected. When I package the same compiled plugin and world file into a production container (using the same Gazebo version and base image), Gazebo starts but the plugin fails to load, producing no visible error in the console output. The goal is to understand why the plugin behaves differently between the two environments despite identical code and Gazebo version, considering factors such as library visibility, environment variables, and container isolation. What steps can I take to verify that GAZEBO_PLUGIN_PATH is correctly set inside the container? How can I confirm that the plugin's shared library is resolvable and compatible with the container's C library? Are there any Gazebo-specific initialization differences between a host and a container runtime that could affect plugin loading?
26525 reputation · 27 Apr 2021, 03:07 UTC
The plugin works on your host because the environment variables GAZEBO_PLUGIN_PATH and LD_LIBRARY_PATH include the directory with the compiled .so, and all required Gazebo libraries are present and ABI‑compatible. Inside the container those variables are often unset or point to different locations, and the container may lack some dependency libraries or run a Gazebo build with a different ABI, causing the loader to silently skip the plugin.
gazeboecho $GAZEBO_PLUGIN_PATH and compare it to the host.gazebo --version inside the container and compare with the version used to compile the plugin (look at CMakeLists.txt or version macros).ldd /path/to/your/plugin.so inside the container; any “not found” entries indicate missing dependencies.GAZEBO_DEBUG=1 gazebo (or gazebo --verbose) and look for lines such as “Failed to load plugin” or “undefined symbol”.docker run -v /host/plugins:/opt/plugins -e GAZEBO_PLUGIN_PATH=/opt/plugins … and see if the plugin loads.Please share the exact output you see when running Gazebo with GAZEBO_DEBUG=1 inside the container (or the relevant lines from gazebo --verbose). That detail will tell us whether the failure is due to a missing library, an ABI mismatch, or another initialization issue and will determine the precise fix.
Use comments to ask for clarification. Post a solution as an answer.
26,525 reputation · 27 Apr 2021, 08:15 UTC
Inside the container, verify that the plugin’s Init symbol is exported and not stripped by running nm -D /path/to/your/plugin.so | grep Init. If the symbol appears as U (undefined) or is missing, the library was built with hidden visibility or stripped, causing Gazebo’s loader to fail silently. Also check the GLIBC version requirements with objdump -T plugin.so | grep GLIBC and compare to the container’s ldd --version output; a mismatch can prevent symbol resolution even when the library loads.