On 01/03/2013 02:01 PM, Brian Gerkey wrote: > hi, > > We recently experienced the following problem: a binary deb that we > build against ROS Fuerte started producing mysterious crashes when > installed on a fresh system. It had previously been working fine, and > still worked fine on some not-freshly installed systems. > > After a bit of head-scratching, we hypothesized that something had > changed in the underlying Fuerte debs. So we tried compiling our > code, without changes, against the latest Fuerte debs. That worked > fine. So we did a no-op re-release of our package, to produce a new > deb built against the latest Fuerte debs. That works fine, too. So, > for now, our problem is solved. Looks like you were right about the symbols. I ran pkg-diff against the drcsim 1.3.0 and 1.3.1 debs. The library libgazebo_ros_controller_manager.so in drcsim-1.3.0 depends on a symbol called _ZN19pr2_mechanism_model10RobotStateD1 Ev that it doesn't depend on in 1.3.1. Digging deeper, this symbol is provided by libpr2_controller_manager.so in ros-fuerte-pr2-mechanism-1.6.1, and gone in ros-fuerte-pr2-mechanism-1.6.4. The reason looks to be that the RobotState class changed between 1.6.1 and 1.6.4 in the pr2_mechanism/pr2_mechanism_model/include/pr2_mechanism_model/robot.h header. Specifically, the RobotState class is inheriting HardwareInterface. A diff of the two versions of robot.h: --- ./1.6.1/opt/ros/fuerte/stacks/pr2_mechanism/pr2_mechanism_model/include/pr2_mechanism_model/robot.h 2012-11-02 18:46:10.000000000 -0400 +++ ./1.6.4/opt/ros/fuerte/stacks/pr2_mechanism/pr2_mechanism_model/include/pr2_mechanism_model/robot.h 2012-12-26 18:54:49.000000000 -0500 @@ -51,6 +51,7 @@ #include #include #include +#include #include "pr2_mechanism_model/joint.h" #include "pr2_mechanism_model/transmission.h" @@ -130,7 +131,7 @@ private: * Some specialized controllers (such as the calibration controllers) can get access * to actuator states, and transmission states. */ -class RobotState +class RobotState : public hardware_interface::HardwareInterface { public: /// constructor @@ -185,7 +186,6 @@ public: void zeroCommands(); -private: std::map joint_states_map_; }; There are a few tools that can be used by the buildsystem to compare new builds to the ones that already exist. pkgdiff is one that can be used offline on two .deb files. The other two are abi-compliance-checker and api-sanity-checker. These both require that a package be installed with all of its dependencies around, but they can generate much better reports of library symbols that are added and removed (pkgdiff required some manual digging). upstream-tracker.org is a good example of a service that runs these tools on new releases of open-source libraries. There were some other removals and reorganizations of packages between the two versions of pr2-controllers and pr2-mechanism as well, I threw everything up online[1][2][3] if you're interested in browsing them. Rich [1] http://richmattes.com/pkgdiff_reports/drcsim/1.3.0_to_1.3.1/compat_report.html [2] http://richmattes.com/pkgdiff_reports/ros-fuerte-pr2-controllers/1.8.0-s1351921336~precise_to_1.8.1-s1356572075~precise/compat_report.html [3] http://richmattes.com/pkgdiff_reports/ros-fuerte-pr2-mechanism/1.6.1-s1351920681~precise_to_1.6.4-s1356571098~precise/compat_report.html