[Ros-release] ABI compatibility
Rich Mattes
richmattes at gmail.com
Thu Jan 3 20:23:49 UTC 2013
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
More information about the Ros-release
mailing list