I am trying to cross-compile a project on my Linux Ubuntu 18.04 WSL for the Raspberry Pi. I have installed the toolchain via sudo apt install gcc-arm-linux-gnueabihf, so it's located unter /usr/bin/.
Now in my CMake File I've set the following:
set(CMAKE_SYSTEM_NAME Linux)
set(CMAKE_SYSTEM_PROCESSOR arm)
set(SYSROOT "${CMAKE_CURRENT_SOURCE_DIR}/../raspi_root")
set(CMAKE_C_COMPILER "/usr/bin/arm-linux-gnueabihf-gcc")
set(CMAKE_CXX_COMPILER "/usr/bin/arm-linux-gnueabihf-g++")
set(CMAKE_SYSROOT ${SYSROOT})
set(CMAKE_FIND_ROOT_PATH ${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)
set(CMAKE_FIND_ROOT_PATH_MODE_PACKAGE ONLY)
raspi_root is the location of my RaspberryPi root file system that I copied from the pi to my WSL.
The CMakeLists.txt then continues in this manner:
set(project_target Project)
project(${project_target})
set(SOURCES
main.cpp
<All my other sources>
)
add_executable(${project_target} ${SOURCES})
find_package(Boost COMPONENTS atomic thread system chrono REQUIRED)
find_library(ALLOTHERLIBS otherlibs REQUIRED)
target_include_directories(${project_target} PUBLIC
${BOOST_INCLUDE_DIR}
${CMAKE_CURRENT_SOURCE_DIR}
${SYSROOT}/usr/include
${SYSROOT}/usr/include/arm-linux-gnueabihf
)
target_link_libraries(${project_target} PUBLIC
${Boost_LIBRARIES}
${ALLOTHERLIBS}
)
Now wenn I do cmake the MakeFile is generated and (almost)* everything succeeds. However, when doing make, I get the following error message:
make[2]: *** No rule to make target '../raspi_root/usr/lib/arm-linux-gnueabihf/libpthread.so', needed by 'Project'. Stop.
CMakeFiles/Makefile2:67: recipe for target 'CMakeFiles/Project.dir/all' failed
make[1]: *** [CMakeFiles/Project.dir/all] Error 2
Makefile:83: recipe for target 'all' failed
make: *** [all] Error 2
To me, still learning CMake and Make, this looks like it's trying to compile the already compiled library libpthread.so. This error disappears when I remove thread from the required boost components. However, then of course the program won't compile because I do use the boost::thread library.
What could be the issue? Why is cmake trying to "make" libpthread.so? Wouldn't any errors concerning the shared library usually appear while linking?
I'm lost for a few days already. Any help would be greatly appreciated.
Best regards Felix
*I say almost because find_package(boost) gives the following warning:
CMake Warning at /usr/share/cmake-3.10/Modules/FindBoost.cmake:801 (message):
New Boost version may have incorrect or missing dependencies and imported
targets
Call Stack (most recent call first):
/usr/share/cmake-3.10/Modules/FindBoost.cmake:907 (_Boost_COMPONENT_DEPENDENCIES)
/usr/share/cmake-3.10/Modules/FindBoost.cmake:1558 (_Boost_MISSING_DEPENDENCIES)
CMakeLists.txt:99 (find_package)
However, my not too thorough Google search told me that this is due to some version difference between CMake and Boost and can be ignored.
Okay, I have found my mistake, thanks to @squareskittles.
When I used rsync to copy the root file system of my Raspberry Pi to my WSL, it "broke" all the links. So in this case /usr/lib/arm-linux-gnueabihf/libpthread.so pointed to the absolute path of the library, namely /lib/arm-linux-gnueabihf/libpthread.so.0.
However on my machine this path was different, since it was located in my raspi_root folder.
I repaired the link with a variant of this handy command (Credits to Mark Wagner)
find ../raspi_root -type l -ls |
awk '$13 ~ /^\// { sub("/","/<MYPATH-TO-RASPI_ROOT/", $13); print $11, $13 }' |
while read A B; do rm $A; ln -s $B $A; done
If I understand correctly this retrieves all links and checks if the destination (argument $13 of find result) starts with '/' meaning the link refers to an absolute path. Then, it replaces the first occurence of '/' with my new path to the root file system.
I think this implies that I must not move or rename the root folder or my links will be broken again.