The ${libdir} variable in pinocchio.pc file wrong when built with catkin

[nielsvd]

Since recently, the pinocchio.pc file generated in a Pinocchio build with catkin (ros noetic) contains an error. This also holds for the package that is distributed by the ros package repository. I can confirm that the same error does not occur when building Pinocchio manually without catkin.

It seems that CMAKE_INSTALL_FULL_LIBDIR is somehow set to be /opt/ros/noetic/lib/x86_64-linux-gnu, because of that the libdir variable in pinocchio.pc also ends up to be this path; regardless of where pinocchio is being installed (e.g., local prefix in local workspace). Since the pinocchio library is actually installed to the lib directory and not lib/x86_64-linux-gnu, linker errors arise.

Although the root cause may not actually be in Pinocchio, I wanted to make you aware of this problem such that you may be able to construct a workaround and have a working version of Pinocchio distributed for ROS (Noetic, not test for other versions).

[nim65s]

additionally, libeigenpy.so & eigenpy.pc are in /opt/ros/noetic/lib/x86_64-linux-gnu, while I would expect this to be at least consistent with pinocchio.

ref. stack-of-tasks/eigenpy#116

[wxmerkt]

Hi @nielsvd
Thank you very much for reporting this. It should work correctly with CMake, but I have not tested this with PkgConfig.

The reason is that we are applying a patch to change the install directory (and amended that patch for EigenPy recently in response to a user request building for Nix). I'll verify the patches for eigenpy and pinocchio and will check that it's consistent -- this may not be immediate though.

Will using CMake (targets) work in the meantime?

[nielsvd]

@wxmerkt , thanks for the response. I'll have a look into using a CMake target instead. Currently, I'm actually patching the pkg-config file manually.

In the meantime there is a bit of extra insight gained. It seems that the problem starts to appear when building Pinocchio with the Python interface. If built without, the PkgConfig file looks correct. To correct an earlier statement, the problem does not seem to limit itself to builds with Catkin, also a manual cmake build leads to a wrong pinocchio.pc (I was previously performing the manual cmake build without the Python interface).

[nielsvd]

I found the source of the problem (from which eigenpyConfig.cmake is generated):
https://github.com/jrl-umi3218/jrl-cmakemodules/blob/b56525c1ba639275892c073e6ef7e54de7672c08/Config.cmake.in#L27

Possible solutions:

• unset the _PKG_CONFIG_LIBDIR variable by the end of the Config.cmake file.
• prepend the _PKG_CONFIG_LIBDIR variable name with the @PROJECT_NAME@.
• Avoid setting _PKG_CONFIG_LIBDIR, use @_PKG_CONFIG_LIBDIR@ in the Config.cmake.

[jcarpent]

@wxmerkt Any update on this?

[wxmerkt]

I am on annual leave right now and have not investigated further -- the above update that it also affects non-catkin builds makes me think the problem is in jrl-cmakemodules and outside of the patch applied for the ROS buildfarm?

It seems that the problem starts to appear when building Pinocchio with the Python interface. If built without, the PkgConfig file looks correct. To correct an earlier statement, the problem does not seem to limit itself to builds with Catkin, also a manual cmake build leads to a wrong pinocchio.pc

Based on this, happy to remove the issue assignment or look at it when I'm back at the end of the month.

[jcarpent]

No problem, we can wait until you're back. Enjoy your holidays!

[jcarpent]

@wxmerkt Would you have time to fix this issue?

[wxmerkt]

Apologies for the slow action on this - and thank you very much @nielsvd for the excellent pointers to the fix. I prepared a fix in jrl-umi3218/jrl-cmakemodules#499 and tested it locally with separate installation workspaces for eigenpy (as the upstream project) and pinocchio (as the downstream project). Using the amended CMake module in EigenPy fixes the generation of the PkgConfig file in Pinocchio.

[wxmerkt]

ROS releases for EigenPy are out (pending merge & sync):

• Noetic: eigenpy: 2.6.9-1 in 'noetic/distribution.yaml' [bloom] ros/rosdistro#31090
• Melodic: eigenpy: 2.6.9-1 in 'melodic/distribution.yaml' [bloom] ros/rosdistro#31091

[jcarpent]

Nice to hear that. I've merged the new cmake feature in #1542.

[grizzi]

Hi. I am facing a probably connected issue.
The tag I am working on v2.6.4 seems to have the correct patch referenced in this issue. I install pinocchio from source and when searching the library with PkgConfig, the library is not found. The pinocchio.pc seems to contain a spurious reference to a default path /opt/openrobots/lib even though the package is installed in a custom install location.

The pinocchio.pc file generated for my install location /home/smb/git/pinocchio/install is:

prefix=/home/smb/git/pinocchio/install
exec_prefix=/home/smb/git/pinocchio/install
libdir=/opt/openrobots/lib  <--- wrong path
bindir=/home/smb/git/pinocchio/install/bin
pkglibdir=/home/smb/git/pinocchio/install/lib/pinocchio
includedir=/home/smb/git/pinocchio/install/include
datarootdir=/home/smb/git/pinocchio/install/share
pkgdatarootdir=/home/smb/git/pinocchio/install/share
docdir=
doxygendocdir=

[nim65s]

Hi @grizzi,
Can you show us which binary packages you have from robotpkg ? With something like dpkg -l robotpkg-\*

[grizzi]

Hi, this is the output of the previous command:

Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name             Version      Architecture Description
+++-================-============-============-=====================================================================
ii  robotpkg-hpp-fcl 1.7.5        amd64        Humanoid Path Planner (collision detection and distance computations)
ii  robotpkg-octomap 1.9.6        amd64        An Efficient Probabilistic 3D Mapping Framework Based on Octrees

I basically installed octomap and hpp-fcl as robotpkgs and then installed pinocchio from source as I needed a build with collision support.

[nim65s]

hpp-fcl v1.7.5 is older than the fix provided in jrl-umi3218/jrl-cmakemodules#499 ; please upgrade it to 1.7.8, and try again to configure and build pinocchio. For this, sudo apt update && sudo apt upgrade should be enough.

[grizzi]

thanks! I can confirm that with the newest version of hpp-fcl the problem is gone :)

[gywhitel]

Similar things happen to me. But it's the include directory, not the library directory.
Using find_package(pinocchio) without using pkg_check_modules works fine. The include directory ${pinocchio_INCLUDE_DIRS} is correct.

-- Checking for module 'pinocchio'
--   Found pinocchio, version 2.6.17
pinocchio include directory: /opt/ros/noetic/lib/pkgconfig/../../include;/opt/ros/noetic/include;/opt/ros/noetic/lib/x86_64-linux-gnu/pkgconfig/../../include;/usr/include/eigen3

However, when using pkg_check_modules(pinocchio REQUIRED pinocchio), ${pinocchio_INCLUDE_DIRS} is somehow set to /opt/ros/noetic/lib/x86_64-linux-gnu/pkgconfig/../../include, which is a non-existing directory and causes error.

Now I have to manually reset ${pinocchio_INCLUDE_DIRS} to correct directory, which works but looks silly.
There probably is some place in the code setting PkgConfig directory incorrectly. But I am not sure how to fix this problem completely.

[nim65s]

Hi @gywhitel,
Thanks for the report, but it's a new issue. Could you open another one ?

[wxmerkt]

@gywhitel Could you switch to using CMake?

[gywhitel]

I walked around this problem by a symbolic link.
Using CMake without pkg_check_module is possible. But the problem to me is happend when compling ocs2_pinocchio_interface, and pinocchio is configured using pkg_ckeck_module in that project.