urdfdom* packages in Indigo/Trusty are in conflict with system ones

[j-rivero]

The full story can be read at https://bitbucket.org/osrf/sdformat/issue/63/gzsdf-segfaults-in-trusty.

The short story, in our efforts to move upstream package to official Ubuntu repositories, the first version already using them is Trusty. Indigo is still shipping ros-indigo-urdfdom*, which I believe should not be needed. Unfortunately, they have the same name but are not ABI compatible, so people with software compiled against system urdfdom libraries, will find a problem if source ROS setup.bash and try to run binary.

IMHO, the way to go would be try to stop using ros-indigo-urdfdom* packages and use the system ones. Not sure about the implications of this for ROS (I imagine that a full recompile of all packages depending on urdfdom is needed. I'm also not sure if a simple change in rosdep can make this transition easy) but please, feel free to propose any other solution you find easier (try to mimic exactly the urdfdom system version in ros-indigio-urdfdom could also work).

As a side note, sorry, I should have detected this problem in the beta phase. I will implement a testing mechanism for this kind of ABI incompatibilities in the OSRF jenkins.

[mikeferguson]

@j-rivero I hit this about an hour ago, and had just found the ticket on sdformat about 20 minutes ago. As @jonbinney pointed out on the sdformat ticket, this will pretty much block the use of gazebo+ros+urdf. I suppose one or the other has to be recompiled -- either we setup ROS Indigo to use the upstream urdfdom, or we have to compile gazebo/sdformat as ROS packages again.

[wjwwood]

One question, is there an official deb for urdfdom on saucy?

[wjwwood]

If there is not (I cannot find one) then we must do several things:

• Import a custom built version of urdfdom which installs to /usr for Saucy into the ROS deb repo
• Remove urdfdom as a ROS package in Indigo
• Add a rosdep rule for urdfdom for Ubuntu
• Rebuild all debs on the ROS build farm which use urdfdom

Also, this makes building on other platforms pretty painful. Currently when building from source, a version of urdfdom is fetched as a ROS package and built as part of the ROS from source build. Once we do the above, any system without urdfdom in the package manager will neither get it from our from source build nor from the package manager. Which means we need to add "create a Homebrew formula for urdfdom" to this list. This will also impact everyone building ros on OS's like Gentoo, Fedora, Arch, Debian, and non-i386/x86-64 Ubuntu systems.

[j-rivero]

@mikeferguson you can trick a little bit the LD_LIBRARY_PATH, check the sdformat bug out for the example. The only point is not to mix software compiled against ROS urdfdom and system urdfdom.

@wjwwood no, saucy has no urdfdom packages. Trusty is the first having them, together with some other known friends: http://qa.debian.org/developer.php?login=jrivero@osrfoundation.org.

I can take care of the homebrew or any other work needed in any other platform. Feel free to assign it to me.

[tfoote]

@isucan @davetcoleman FYI

The version in Trusty is 0.2.10 and in indigo it's 0.3.0. I believe I remember a discussion about 0.3.0 being required for something but I don't know what.

[tfoote]

Also @hsu FYI

[j-rivero]

@tfoote 0.3.0 in Indigo but the library file name and soname are 0.2?

(trusty)jrivero@nium ~ $ readelf -a  /opt/ros/indigo/lib/liburdfdom_model.so.0.2  | grep SONAME
 0x000000000000000e (SONAME)             Library soname: [liburdfdom_model.so.0.2]

Probably it is not ABI compatible so any reason not to use a proper soname/soversion?

Could be a short-term fix to not affect to all distributions, patch ros-indigo-urdfdom*, use 0.3 soversion and launch the whole re-release process?

[davetcoleman]

The biggest change I know of for urdfdom is in urdfdom_headers where a undocumented group name member variable was removed from links. This would cause the ABI compatibility. This change has caused changes in Rviz, so it might not be easy to undo it. I also put some minor changes into urdfdom that I would be sad to see not released into indigo, since I have been waiting for them to be released for a year now (since Hydro).

[davetcoleman]

The rviz changes has a compiler if statement for differing versions of urdfdom
ros-visualization/rviz@09bc0e0#diff-deb887957b4c886cf99b6fa13089be45R653

[wjwwood]

@davetcoleman what changes are in master of urdfdom which are not in 0.2.3 which you would like to see in Indigo.

We are hoping that there is an ABI compatible way to have 0.2.3 in /usr AND the the features you want.

[wjwwood]

Let me be more specific, currently in Trusty:

• urdfdom 0.2.10
• urdfdom_headers 0.2.3

Currently in Indigo:

• urdfdom 0.3.0
• urdfdom_headers 0.3.0

Now, I believe that the changes in urdfdom_headers between 0.2.3 and 0.3.0 are trivial and not required for Indigo (@isucan may disagree?), therefore we can roll back the version of that to 0.2.3 for Indigo (allowing us to remove urdfdom_headers from ROS and just use Trusty's). The question for @davetcoleman is:

What changes between 0.2.10 and 0.3.0 of urdfdom are important for Indigo?

ros/urdfdom@0.2.10...0.3.0

If we can determine that then we can see if we can back port those changes to a 0.2.11 of urdfdom which uses 0.2.3 urdfdom_headers and can be released into Trusty as a patch release.

[davetcoleman]

I would like to see in Indigo this very minor change, which is abi -compatible: ros/urdfdom@cc286e3

It just drastically reduces the amount of noise when using MoveIt in debug logging level.

I also have some trivial commits to README.md. Everything else I am not involved in so don't know, but I don't see (reading through the code just now) any changes to header files so perhaps we can backport all the changes?

[scpeters]

After discussing with @wjwwood , we think the next step should be to create a branch called 0.2 and cherry pick @davetcoleman 's commits to it in order to make a patch release to send into ubuntu.

@hsu as a maintainer, can you create the 0.2 branch? I will make pull requests to it, but only a maintainer can create branches.

[hsu]

branch created
On Jun 6, 2014 2:32 PM, "Steven Peters" notifications@github.com wrote:

After discussing with @wjwwood https://github.com/wjwwood , we think
the next step should be to create a branch called 0.2 and cherry pick
@davetcoleman https://github.com/davetcoleman 's commits to it in order
to make a patch release to send into ubuntu.

@hsu https://github.com/hsu as a maintainer, can you create the 0.2
branch? I will make pull requests to it, but only a maintainer can create
branches.

—
Reply to this email directly or view it on GitHub
#4633 (comment).