This means that if a symbol from libpinocchio is actually used, the downstream library will link to libpinocchio.so.2.6.16, and so it will give an error if libpinocchio.so.2.6.17 is installed (that is indeed the bug in https://github.com/stack-of-tasks/tsid/issues/199). However, the recipe contains:
That for example means that any downstream library that is build with pinocchio 2.6.16 will depend at runtime to pinocchio with constraint pinocchio>=2.6.16, pinocchio<2.17 .
Depending on whater the pinocchio ABI policy is, the right thing to do is:
If no ABI break is permitted in patch versions, then we should fix the CMake of pinocchio to not use 2.6.16 as soname, but just 2.6
IF ABI breaks are permitted in patch versions, or if no one is tracking ABI changes, then we should change pinocchio recipe for have:
Thanks a lot @traversaro for the issue and the fix suggestions. I've applied the second strategy as it seems more aligned with the release strategy of Pinocchio.
Solution to issue cannot be found in the documentation.
Issue
I noticed (after reading https://github.com/stack-of-tasks/tsid/issues/199) that downstream code that links pinocchio links the library with the full soname until the patch number, i.e. :
This means that if a symbol from
libpinocchio
is actually used, the downstream library will link tolibpinocchio.so.2.6.16
, and so it will give an error iflibpinocchio.so.2.6.17
is installed (that is indeed the bug in https://github.com/stack-of-tasks/tsid/issues/199). However, the recipe contains:That for example means that any downstream library that is build with pinocchio 2.6.16 will depend at runtime to pinocchio with constraint pinocchio>=2.6.16, pinocchio<2.17 .
Depending on whater the pinocchio ABI policy is, the right thing to do is:
2.6.16
as soname, but just2.6
to ensure that the correct run constraint is used.
Installed packages
Environment info