Problems intalling teo-main ubuntu 16.04

[jmgarciah]

[ 56%] Building CXX object libraries/TeoYarp/KdlSolver/CMakeFiles/KdlSolver.dir/ICartesianSolverImpl.cpp.o In file included from /home/jmgarciah/repos/teo-main/libraries/TeoYarp/KdlSolver/KdlSolver.hpp:23:0, from /home/jmgarciah/repos/teo-main/libraries/TeoYarp/KdlSolver/ICartesianSolverImpl.cpp:3: /home/jmgarciah/repos/teo-main/libraries/TeoYarp/KdlSolver/ICartesianSolverImpl.cpp: In member function ‘virtual bool teo::KdlSolver::invDyn(const std::vector&, std::vector&)’: /home/jmgarciah/repos/teo-main/libraries/TeoYarp/KdlSolver/ICartesianSolverImpl.cpp:168:42: error: ‘class KDL::ChainIdSolver_RNE’ has no member named ‘strError’ CD_ERROR("%d: %s\n",ret,idsolver.strError(ret)); ^ /home/jmgarciah/repos/teo-main/libraries/ColorDebug/ColorDebug.hpp:106:29: note: in definition of macro ‘CD_ERROR’ fprintf(stderr, VA_ARGS__);} while(0); fprintf(stderr,RESET);} ^ /home/jmgarciah/repos/teo-main/libraries/TeoYarp/KdlSolver/ICartesianSolverImpl.cpp:173:45: error: ‘class KDL::ChainIdSolver_RNE’ has no member named ‘strError’ CD_WARNING("%d: %s\n",ret, idsolver.strError(ret)); ^ /home/jmgarciah/repos/teo-main/libraries/ColorDebug/ColorDebug.hpp:120:29: note: in definition of macro ‘CD_WARNING’ fprintf(stderr, VA_ARGS);} while(0); fprintf(stderr,RESET);} ^ /home/jmgarciah/repos/teo-main/libraries/TeoYarp/KdlSolver/ICartesianSolverImpl.cpp: In member function ‘virtual bool teo::KdlSolver::invDyn(const std::vector&, const std::vector&, const std::vector&, const std::vector<std::vector >&, std::vector&)’: /home/jmgarciah/repos/teo-main/libraries/TeoYarp/KdlSolver/ICartesianSolverImpl.cpp:213:42: error: ‘class KDL::ChainIdSolver_RNE’ has no member named ‘strError’ CD_ERROR("%d: %s\n",ret,idsolver.strError(ret)); ^ /home/jmgarciah/repos/teo-main/libraries/ColorDebug/ColorDebug.hpp:106:29: note: in definition of macro ‘CD_ERROR’ fprintf(stderr, __VA_ARGS);} while(0); fprintf(stderr,RESET);} ^ /home/jmgarciah/repos/teo-main/libraries/TeoYarp/KdlSolver/ICartesianSolverImpl.cpp:218:44: error: ‘class KDL::ChainIdSolver_RNE’ has no member named ‘strError’ CD_WARNING("%d: %s\n",ret,idsolver.strError(ret)); ^ /home/jmgarciah/repos/teo-main/libraries/ColorDebug/ColorDebug.hpp:120:29: note: in definition of macro ‘CD_WARNING’ fprintf(stderr, __VA_ARGS__);} while(0); fprintf(stderr,RESET);} ^ libraries/TeoYarp/KdlSolver/CMakeFiles/KdlSolver.dir/build.make:110: fallo en las instrucciones para el objetivo 'libraries/TeoYarp/KdlSolver/CMakeFiles/KdlSolver.dir/ICartesianSolverImpl.cpp.o' make[2]: [libraries/TeoYarp/KdlSolver/CMakeFiles/KdlSolver.dir/ICartesianSolverImpl.cpp.o] Error 1 CMakeFiles/Makefile2:623: fallo en las instrucciones para el objetivo 'libraries/TeoYarp/KdlSolver/CMakeFiles/KdlSolver.dir/all' make[1]: [libraries/TeoYarp/KdlSolver/CMakeFiles/KdlSolver.dir/all] Error 2 Makefile:127: fallo en las instrucciones para el objetivo 'all' make: *** [all] Error 2

[jmgarciah]

previously, I install KDL from the package (sudo apt-get install liborocos-kdl-dev)

[PeterBowman]

Did you install ROS? See #40.

[jgvictores]

@PeterBowman @jmgarciah No, this is actually a duplicate I'll mark later on. KDL for now must be (uninstalled from apt-get, and) installed from source to get the missing functions.

[PeterBowman]

The commit that prevented this error from occurring in upstream KDL 1.4.0 (liborocos-kdl-dev xenial package corresponds to version 1.3.0) was orocos/orocos_kinematics_dynamics@9dd3f23.

As an alternative to uninstalling the package, this would be pretty simple to fix in TEO code. In libraries/TeoYarp/KdlSolver/ICartesianSolverImpl.cpp, substitute any strError occurrences like the next one:

if(ret < 0)
{
    CD_ERROR("%d: %s\n",ret,idsolver.strError(ret));
    return false;
}

for:

if(ret < 0)
{
    KDL::SolverI si;
    CD_ERROR("%d: %s\n",ret,si.strError(ret));
    return false;
}

However, a helper function in the teo:: namespace might be a better choice.

[jgvictores]

@PeterBowman My main idea to keep with the source install was to some day fix #15. :smile:

[jmgarciah]

finally, I uninstalled the KDL package and I reinstalled from the source. After thism, I could compile the teo-main repository without any problem.

Thx

[jgvictores]

@PeterBowman With #15 in mind (and no intention to bias you towards my own opinion 😄), what is your opinion on removing the apt-get solution from the install guide (or commenting on reasons against it) and closing this issue?

[PeterBowman]

@jgvictores I'm totally OK with that, the apt-get part has been just removed at roboticslab-uc3m/installation-guides@b4e74a9.

[jgvictores]

Cool, thanks! Closing!

[PeterBowman]

I committed f782768 to make clear what is the root cause of the problem (an unsupported KDL 1.3.0 package is picked by CMake during the configuration step) and provide a hint for users to follow (git clone and compile latest master, as detailed in our installation guides). However, CMake is smart enough to locate KDL at /opt/ros/<distro>/share/orocos_kdl, dismiss it as it doesn't match the version parameter passed to find_package, and move on to the system- or user-installed (usually somewhere in /usr/local) KDL binaries.

Long story short, this is now fixed and no action is required by the user concerning KDL support with both YARP and ROS environments installed on the same machine.

[jgvictores]

@PeterBowman That's extremely interesting and much better than any solution provided here or on #40

However, I've opened #128 as the root of this requirement might be based on a false assumption.

[PeterBowman]

I just learned that CMake will still pick KDL 1.3 when the find_package(orocos_kdl) call is issued before reaching KdlSolver's tree, wherein find_package(orocos_kdl 1.4) is used. Not so surprising at all if we think about it, but it needs a second cmake .. run to get everything on the right track. To avoid this somewhat random behavior, I committed 65c4969.

BTW the linker warns about version mismatches:

/usr/bin/ld: warning: liborocos-kdl.so.1.3, needed by ../../lib/libKdlVectorConverterLib.so, may conflict with liborocos-kdl.so.1.4

I noticed this when KdlSolver's builds got the usual strError notices and failed. KdlSolver itself depends on KdlVectorConverterLib, which was configured with KDL 1.3, and hence propagated its usage requirements (v1.3 shared libs and headers). This is not obvious at the first glance since CMake's cache is populated with KDL v1.4 config variables upon returning from the configuration step.