Compiling issue after adding hash function? about orocos_kinematics_dynamics

[MatthijsBurgh]

Try to build with --force-cmake.

If that doesn't fix the issue, set the cpp version both in orocos_kdl and python_ocoros_kdl to cpp14. Maybe that will do the job.

Have you tried building the python2 version. As on ubuntu 18.04 the CI succeeds for python2.

[martinmatak]

Tried adding --force-cmake --> same issue
Tied adding set(CMAKE_CXX_FLAGS "-std=c++14 ${CMAKE_CXX_FLAGS}") to both CMakeLists.txt files --> same issue
Tried combining the two approaches above --> Same issue
Checked out commit 6480921b236baacf282d32857c9a4a1c6f9bd971 --> all good i.e. it compiles

I don't really want to build it with python 2 because I need to use it with Python3

[MatthijsBurgh]

I have run a test in GH actions, https://github.com/orocos/orocos_kinematics_dynamics/runs/6841870108, which does succeed. So it should be able to work.

[martinmatak]

Did you get it to work with catkin build?

[MatthijsBurgh]

I did not test with catkin build in combination with 18.04 and python3. Testing that in CI is not that straight forward I think. Could you check if the plain cmake/make does work for you? (Maybe not the installing, just the cmake and make from https://github.com/orocos/orocos_kinematics_dynamics/blob/master/python_orocos_kdl/INSTALL.md)

[MannavaVivek]

I am facing the same issue with Ubuntu 20.04 and python 3.8
I have tried all the fixes mentioned here, but nothing is working.

[MatthijsBurgh]

The CI does test cmake/make on Ubuntu 20.04 with python 3.8. which succeeds.
I am running the same versions on my own machine. I use catkin build on it. Which also works. With catkin build you need to run it once with --force-cmake.

@MannavaVivek please provide more insight in your machine and the steps you took

[MannavaVivek]

I did use catkin build with --force-cmake but the results were the same.
The only thing I could think of is the gcc version (mine is gcc 9.4.0).
I also pulled the code from the commit mentioned above 6480921b236baacf282d32857c9a4a1c6f9bd971 and was able to build it without issues. In all cases, only python_orocos_kdl had the error, while orocos_kdl built without issues.

[MatthijsBurgh]

I am not sure what the easiest way to get this information. --verbose might do the job. But could you get the found paths of orocos_kdl and pybind during the PyKDL build. When these mismatch we have likely found the cause.

[MatthijsBurgh]

@MannavaVivek I figured out this is caused by an incompatible pybind version. One installed on your system, not the one in the submodule. If you had responded to my last question about providing the paths of the found libraries we would have found the issue much earlier. Which would have trouble for other people as well.

So next time please respond, when somebody is helping you.