ROS Resources: Documentation | Support | Discussion Forum | Index | Service Status | ros @ Robotics Stack Exchange
Ask Your Question
0

Why no /opt/ros/kinetic/lib/*.so soname version?

asked 2020-02-04 10:10:05 -0500

rubicks gravatar image

updated 2020-02-04 15:01:53 -0500

Here's what I can see (abbreviated) on a typical Ubuntu Xenial installation of Kinetic:

$ find /opt/ros/kinetic/lib -maxdepth 1 -type f -name '*.so' -exec objdump -p {} \; | grep SONAME | head
  SONAME               libresource_retriever.so
  SONAME               libpcl_ros_filters.so
  SONAME               libinteractive_markers.so
  SONAME               libtf.so
  SONAME               librosbag.so
  SONAME               librosconsole_bridge.so
  SONAME               libnodeletlib.so
  SONAME               libpcl_ros_features.so
  SONAME               liburdf.so
  SONAME               libsimple_message_dummy.so

Here's a view of the "host multiarch" directory on the same installation:

$ find /opt/ros/kinetic/lib/x86_64-linux-gnu/ -maxdepth 1 -type f -name '*.so.*' -exec objdump -p {} \; | grep SONAME | head
  SONAME               libopencv_video3.so.3.3
  SONAME               libopencv_rgbd3.so.3.3
  SONAME               libopencv_stitching3.so.3.3
  SONAME               libopencv_xfeatures2d3.so.3.3
  SONAME               libopencv_viz3.so.3.3
  SONAME               libopencv_imgproc3.so.3.3
  SONAME               libopencv_xphoto3.so.3.3
  SONAME               libopencv_features2d3.so.3.3
  SONAME               libopencv_ximgproc3.so.3.3
  SONAME               libopencv_bgsegm3.so.3.3

Why do the former lack soname versions? Why do only the latter have soname versions? Why does setup.sh export LD_LIBRARY_PATH such that the former path precedes the latter (causing the linker to find the _unversioned_ shared objects in lieu of the versioned ones)?


Follow up question: Is there anything obviously wrong with doing something like the following?

find "/opt/ros/${ros_distro}/lib" -maxdepth 1 -type f -name '*.so' -exec dpkg -S {} + \
    | tr -s ': ' '\t' \
    | while read package sofile; do
    version="$(dpkg -s "${package}" | awk '/^Version: /{print $NF}')"
    output="/etc/dpkg/symbols/${package}.symbols"
    mkdir -vp "$(dirname "${output}")"
    dpkg-gensymbols -e"${sofile}" -p"${package}" -v"${version}" -O"${output}"
done

I.e., Is generating symbols files for every unversioned shared object a reasonable solution to this problem?

edit retag flag offensive close merge delete

1 Answer

Sort by ยป oldest newest most voted
2

answered 2020-02-04 11:09:20 -0500

gvdhoorn gravatar image

updated 2020-02-04 11:19:22 -0500

More of a comment as this is all IIUC.

Why do the former lack soname versions?

There is no ABI compatibility guarantee for any of the ROS 1 packages. See REP-9 for an early rejected REP that dealt with this subject.

In addition to this (or maybe because of it, although one does not exclude the other), there is no soname policy in ROS 1. So most of the libraries shipped in ROS 1 packages will not have the (ABI) version appended.

Why do only the latter have soname versions?

There are some exceptions which do have it, such as OpenCV, but that is because the upstream projects they come from already have them. MoveIt would be another exception.

Why does setup.sh export LD_LIBRARY_PATH such that the former path precedes the latter (causing the linker to find the _unversioned_ shared objects in lieu of the versioned ones)?

This I can't answer conclusively. That's probably something @Dirk Thomas could answer.

edit flag offensive delete link more

Comments

note that there is some work in the direction of ABI compatibility (ie: explicitly stating it and checking for it).

REP-149: Package Manifest Format Three Specification for instance adds the compatibility attribute to the version element in package manifests (here). And ros_buildfarm gained the ability to run an ABI checker for certain jobs with the merge of ros-infrastructure/ros_buildfarm#681.

AFAIK there is still no "Debian style" ABI compatibility guarantee, but the situation is improving.

gvdhoorn gravatar image gvdhoorn  ( 2020-02-04 11:16:38 -0500 )edit

There are quite a few old(er) discussions about this on the ros-users mailing list IIRC. You may want to look for those if you're interested in the history around this subject.

gvdhoorn gravatar image gvdhoorn  ( 2020-02-04 11:21:40 -0500 )edit

I've posted an amendment to my original question --- one that concerns the generation of symbols files for the ROS unversioned shared objects. It seems to do what I want, but I'd like to hear other opinions.

rubicks gravatar image rubicks  ( 2020-02-04 15:03:14 -0500 )edit

That should really be a new question.

And I'm starting to wonder whether this is going in the direction of an xy-problem. You don't mention anywhere what problem you are trying to solve here (but again: that should be in a new question).

gvdhoorn gravatar image gvdhoorn  ( 2020-02-04 15:06:19 -0500 )edit

@gvdhoorn Here's the problem: Build and package something for Debian that depends on symbols from any ROS library. How does one discover the run-time dependencies if those packages do not provide symbols files?

rubicks gravatar image rubicks  ( 2020-02-04 17:40:38 -0500 )edit

So this is an xy-problem. The question here is only part of it, and your last edit goes into the direction of a solution you've already chosen yourself.

I would suggest to post that as a new question and accept the answer on this one.

Unless you want to wait for @Dirk Thomas to comment on the last parts of course.

Although you may want to post that as a separate question as well, as it doesn't seem connected to the first question(s) about sonames.

gvdhoorn gravatar image gvdhoorn  ( 2020-02-05 02:32:58 -0500 )edit

As to the symbol files: starting with Melodic the buildfarm generates -dbg packages for all .debs which include all the symbols.

gvdhoorn gravatar image gvdhoorn  ( 2020-02-05 02:36:33 -0500 )edit

I think you're confusing the debug package (automatically produced by debhelper >= 9.20151219) with the Debian symbols system (files produced by dpkg-gensymbols and consumed by dpkg-shlibdeps).

rubicks gravatar image rubicks  ( 2020-02-05 08:52:12 -0500 )edit

Question Tools

2 followers

Stats

Asked: 2020-02-04 10:10:05 -0500

Seen: 356 times

Last updated: Feb 04 '20