[Ros-release] ABI compatibility

[Rich Mattes]

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 <string>
  #include <urdf/model.h>
  #include <pr2_hardware_interface/hardware_interface.h>
+#include <hardware_interface/hardware_interface.h>
  #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<std::string, JointState*> 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