nav2_smac_planner not finding ode_double.lib about ros-humble HOT 11 CLOSED

Oddly enough, the logs did not mention that it looked for ode?!?

This is indeed strange, even if I am not really sure who is printing Found: <pkg> .

Probably we can add a message(STATUS "=====================> MESSAGE") to the patch to make sure that it is actually applied and we are not missing anything on that side?

from ros-humble.

By the way, when trying to build move it another weird error occurs.. https://github.com/RoboStack/ros-humble/actions/runs/3693026840

A possible patch (untested) could be moveit/moveit2@dd3cd32 .

from ros-humble.

There is something strange in the omplConfig.cmake:

foreach(_lib D:/bld/ompl_1667488141743/_h_env/Library/lib/boost_serialization.lib;D:/bld/ompl_1667488141743/_h_env/Library/lib/boost_filesystem.lib;D:/bld/ompl_1667488141743/_h_env/Library/lib/boost_system.lib;ode_double;)
    if(_lib)
        list(APPEND OMPL_LIBRARIES "${_lib}")
    endif()
endforeach()

Apparently just doing target_link_libraries([..] ode_double) does not work, even if ode_double.lib is in a known location. Probably a quick fix that we could attemp is just to replace ode_double with ODE::ODE, that should work fine, i.e. to add after find_package(ompl REQUIRED) and find_package(ode REQUIRED):

string(REPLACE "ode_double" "ODE::ODE" OMPL_LIBRARIES ${OMPL_LIBRARIES})

In that case, all the manual linnks to ${ODE_LIBRARIES} (that just contains ODE::ODE) could be removed.

Sorry, perhaps it is more robust:

list(REMOVE_ITEM OMPL_LIBRARIES "ode_double")
list(APPEND OMPL_LIBRARIES "ODE::ODE")

from ros-humble.

Both the moveit as well as the navigation2 issues have been resolved. Thanks so much @traversaro!!!

from ros-humble.

For reference, this is the failing job: https://github.com/RoboStack/ros-humble/actions/runs/3689749512/jobs/6246043717 .

from ros-humble.

There is something strange in the omplConfig.cmake:

foreach(_lib D:/bld/ompl_1667488141743/_h_env/Library/lib/boost_serialization.lib;D:/bld/ompl_1667488141743/_h_env/Library/lib/boost_filesystem.lib;D:/bld/ompl_1667488141743/_h_env/Library/lib/boost_system.lib;ode_double;)
    if(_lib)
        list(APPEND OMPL_LIBRARIES "${_lib}")
    endif()
endforeach()

Apparently just doing target_link_libraries([..] ode_double) does not work, even if ode_double.lib is in a known location. Probably a quick fix that we could attemp is just to replace ode_double with ODE::ODE, that should work fine, i.e. to add after find_package(ompl REQUIRED) and find_package(ode REQUIRED):

string(REPLACE "ode_double" "ODE::ODE" OMPL_LIBRARIES ${OMPL_LIBRARIES})

In that case, all the manual linnks to ${ODE_LIBRARIES} (that just contains ODE::ODE) could be removed.

from ros-humble.

Oddly enough, the logs did not mention that it looked for ode?!?

This is indeed strange, even if I am not really sure who is printing Found: <pkg> .

from ros-humble.

Thanks Silvio - let’s see what happens :)

from ros-humble.

By looking at all the packages looked for, not all of them generate a Found <> message, for example:

• pluginlib
• nav2_msgs
• nav_msgs
• builtin_interfaces

Do not generate any message.

from ros-humble.

Ok, I think only packages that export a version (via a <pkg>Version.cmake file) print a message when found or packages that are found via a Find<pkg>.cmake module. It seems that packages that are find via a -config.cmake file and without a corresponding version file do not print anything, but I did not validate this hypothesis.

from ros-humble.

By the way, when trying to build move it another weird error occurs.. https://github.com/RoboStack/ros-humble/actions/runs/3693026840

from ros-humble.