交叉编译ROS Melodic on RaspberryPi 3B+问题

Cross-Compiling ROS Melodic on RaspberryPi 3B+ Problem

经过一些研究,我发现没有一种单一的 "tried-and-true" 方式可以为 RaspberryPi 交叉编译 ROS。我能想到的最好办法是从目标设备下载 /usr/lib/opt 到我的开发机器(安装在 $HOME/Projects/TargetResources),制作一个 CMake 工具链文件,并调用 catkin_make_isolated -DCMAKE_TOOLCHAIN_FILE=...。虽然构建过程开始了,但我立即遇到错误:

$ catkin_make_isolated -DCMAKE_TOOLCHAIN_FILE=${HOME}/Projects/${MY_PROJ}/RPI3+_Melodic_Toolchain.cmake
CMake Error at ${HOME}/Projects/TargetResources/opt/ros/melodic/share/catkin/cmake/assert.cmake:17 (message):
Assertion failed: check for file existence, but filename
  (RT_LIBRARY-NOTFOUND) unset.  Message: RT Library

Call Stack (most recent call first):

  ${HOME}/Projects/TargetResources/opt/ros/melodic/share/catkin/cmake/tools/rt.cmake:42 (assert_file_exists)
  ${HOME}/Projects/TargetResources/opt/ros/melodic/share/catkin/cmake/all.cmake:159 (include)
  ${HOME}/Projects/TargetResources/opt/ros/melodic/share/catkin/cmake/catkinConfig.cmake:20 (include)
  CMakeLists.txt:10 (find_package)

经过一些挖掘,目标设备(即 RaspberryPi 3+)没有 librt.so。有趣的是,如果我只是 运行 catkin_make 用于设备上的项目,一切都会成功构建。所以我不认为尝试安装它真的有必要(或正确的解决方案)。

此外,我应该注意到目标安装了 ROS Melodic Base,而我的开发机器安装了 ROS Melodic Desktop。我不确定这是否会导致我遇到的问题,但我不想过早地排除它。

所以,我的问题是我应该如何进行?我是否在设置工具链时忽略了某些东西,或者我是否假设有关 ROS/Catkin 的某些东西是错误的?

预先感谢您的所有帮助和考虑。

编辑/补遗

根据要求,这里是工具链文件:

set(CMAKE_SYSTEM_NAME Linux)
set(CMAKE_SYSTEM_VERSION 1)

SET(CMAKE_C_COMPILER   $ENV{HOME}/Projects/RpiDevTools/arm-bcm2708/arm-rpi-4.9.3-linux-gnueabihf/bin/arm-linux-gnueabihf-gcc)
SET(CMAKE_CXX_COMPILER $ENV{HOME}/Projects/RpiDevTools/arm-bcm2708/arm-rpi-4.9.3-linux-gnueabihf/bin/arm-linux-gnueabihf-g++)

SET(CMAKE_FIND_ROOT_PATH $ENV{HOME}/Projects/RpiDevTools/arm-bcm2708/arm-rpi-4.9.3-linux-gnueabihf/arm-linux-gnueabihf/sysroot/)

set(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER)
set(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY)
set(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY)

sysroot 中,我复制了 RaspberryPi 的 /opt 目录,因为这是安装 ROS Melodic 库的地方。我发现那些库可能具有在 RaspberryPi/Tools sysroot/usr/include 目录中找不到的依赖项(例如 log4cxx/level.h)。同样,解决共享对象依赖关系同样麻烦。

问题似乎源于交叉编译工具本身:使用 arm-linux-gnueabihf-gcc & arm-linux-gnueabihf-g++ 来自 https://github.com/raspberrypi/tools 意味着编译器在预编译器中配置了 libc 库已知配置。例如,math.h包括bits/math-vector.h;在 GitHub 的 RaspberryPi 工具中,它位于 .../sysroot/usr/include/bits,而直接从 RaspberryPi 3B+ 本身复制的位于 /usr/include/arm-linux-gnueabf/bits。各自的编译器(本机和交叉编译)是用它们各自的配置构建的,而不是其他的,并且不搜索(很好)通用路径。