cross-compile with research ISA

[dodsonmg]

I would like to cross-compile ROS2 onto a research platform with a new ABI and an extension to the RISC-V ISA. I need some help either manually building or making use of the existing cross-compile tools.

My test applications are fairly simple, and I was able to cross-compile ROS[1] applications manually (i.e., avoiding catkin) by converting them to rosserial applications. I eventually built an entire TurtleBot3 for my research platform this way (including teleop).

Now I'm looking to ROS2 for some of its real-time possibilities.

My normal cross-compile invocation for a rosserial application is something like this:

    $HOME/cheri/output/sdk/bin/cheri-unknown-freebsd-clang++ \
            $SRC1 $SRC2 -o $BIN \
            -g \
            -I$HOME/ros_lib \
            -mabi=purecap \
            --sysroot=$HOME/cheri/output/sdk/sysroot128 \

I'm not sure I can get this to translate to the docker/QEMU-based cross-compile tool.

Is there a simpler way for me to use colcon or a recommendation for calling cmake directly?

I'm only trying to build a simple C++ talker/listener demo at this point, so we're talking one package, two source files, and one message type.

---

What I've tried so far:

I have a cmake toolchain file which sets the C and CXX compiler variables and the SYSROOT variables.

I attempt to run colcon with the following invocation:

colcon build --ament-cmake-args -DCMAKE_TOOLCHAIN_FILE=/home/broomstick/ros2_cmake_test/CrossToolchain.cmake

It churns through several projects just fine, and then I get the following failure:

Starting >>> rcutils
--- stderr: rcutils                                                                                                            
CMake Error at /usr/share/cmake-3.10/Modules/FindPackageHandleStandardArgs.cmake:137 (message):
  Could NOT find PythonLibs (missing: PYTHON_LIBRARIES PYTHON_INCLUDE_DIRS)
  (Required is at least version "3.5")
Call Stack (most recent call first):
  /usr/share/cmake-3.10/Modules/FindPackageHandleStandardArgs.cmake:378 (_FPHSA_FAILURE_MESSAGE)
  /usr/share/cmake-3.10/Modules/FindPythonLibs.cmake:262 (FIND_PACKAGE_HANDLE_STANDARD_ARGS)
  /home/broomstick/ros2_cmake_test/install/python_cmake_module/share/python_cmake_module/cmake/Modules/FindPythonExtra.cmake:133 (find_package)
  /home/broomstick/ros2_cmake_test/install/launch_testing_ament_cmake/share/launch_testing_ament_cmake/cmake/launch_testing_ament_cmake-extras.cmake:18 (find_package)
  /home/broomstick/ros2_cmake_test/install/launch_testing_ament_cmake/share/launch_testing_ament_cmake/cmake/launch_testing_ament_cmakeConfig.cmake:38 (include)
  /home/broomstick/ros2_dashing/install/ament_lint_auto/share/ament_lint_auto/cmake/ament_lint_auto_find_test_dependencies.cmake:36 (find_package)
  CMakeLists.txt:120 (ament_lint_auto_find_test_dependencies)

Perhaps catastrophically, the target system doesn't support python (yet). All the test applications I want to build are C/C++. Is it possible for me to cross-compile a simple C/C++ application without python support on the target?

---

I asked this question on ROS Answers, and van der Hoorn suggested I post an issue here, as it seemed similar to #69.

[emersonknapp]

Is it possible for me to cross-compile a simple C/C++ application without python support on the target?

I'm still thinking about how to help with the rest, but the answer to this part is yes. If you provide the --cmake-args -DBUILD_TESTING=NO, it will disable trying to build the tests, which will skip the python dependencies on launch

You can see an example of me doing this exact thing here https://github.com/emersonknapp/ros2-toolchain-crosscompile/blob/master/docker/cross-compile.mixin - I am calling colcon with the linaro sysroot and toolchain to cross compile a subset of the ros2 core for a custom system. I'd like to support this use case here in the cross_compile tool, but I'd say we're a little ways away from that.

Let me know if this helps you out with your use case, and if so we can close this particular issue.

[dodsonmg]

This works!

I've also needed to add -DTHIRDPARTY=ON to correctly link my cross-compiled asio library.

--no-warn-unused-cli from your example was also very helpful.

I'm now fighting through some other issues (namely that many Linux header files have more includes than their FreeBSD counterparts), but making progress.