CMake Cross Compilation secondary dependencies - cmake

Question

I have a program that compiles on my target machine (NVIDIA Jetson). Now I am trying to cross compile the same program on my laptop. I have a cross compiler and cloned the Jetson to use as a sysroot. I was following this guide from NVIDIA. My program compiles, but fails at a linking step. I'm linking against a library (protobuf) and the linker can't find the dependencies of the library. I have produced a minimal example that demonstrates this.
main.cpp:
#include <google/protobuf/util/json_util.h>
int main(int argc, char* argv[])
{
google::protobuf::util::JsonPrintOptions jsonOptions;
jsonOptions.always_print_enums_as_ints = true;
return 0;
}
CMakeLists.txt:
cmake_minimum_required(VERSION 3.20)
project(Test)
find_package(Protobuf REQUIRED)
add_executable(Test main.cpp)
target_include_directories(Test PRIVATE ${PROTOBUF_INCLUDE_DIRS})
target_link_libraries(Test PRIVATE ${PROTOBUF_LIBRARIES})
On my target computer CMake generates and builds this fine, but when cross compiling on my laptop CMake generates the makefiles, and the build step fails with the error:
[ 50%] Building CXX object CMakeFiles/Test.dir/main.cpp.o
[100%] Linking CXX executable Test
/home/lhahn/Documents/CrossCompilation/gcc-linaro-7.3.1-2018.05-x86_64_aarch64-linux-gnu/bin/../lib/gcc/aarch64-linux-gnu/7.3.1/../../../../aarch64-linux-gnu/bin/ld: warning: libz.so.1, needed by /home/lhahn/Documents/CrossCompilation/Images/jetson/usr/local/lib/libprotobuf.so, not found (try using -rpath or -rpath-link)
/home/lhahn/Documents/CrossCompilation/gcc-linaro-7.3.1-2018.05-x86_64_aarch64-linux-gnu/bin/../lib/gcc/aarch64-linux-gnu/7.3.1/../../../../aarch64-linux-gnu/bin/ld: warning: libm.so.6, needed by /home/lhahn/Documents/CrossCompilation/gcc-linaro-7.3.1-2018.05-x86_64_aarch64-linux-gnu/bin/../lib/gcc/aarch64-linux-gnu/7.3.1/../../../../aarch64-linux-gnu/lib/../lib64/libstdc++.so, not found (try using -rpath or -rpath-link)
/home/lhahn/Documents/CrossCompilation/Images/jetson/usr/local/lib/libprotobuf.so: undefined reference to `deflateInit2_'
/home/lhahn/Documents/CrossCompilation/Images/jetson/usr/local/lib/libprotobuf.so: undefined reference to `deflate'
/home/lhahn/Documents/CrossCompilation/Images/jetson/usr/local/lib/libprotobuf.so: undefined reference to `deflateEnd'
/home/lhahn/Documents/CrossCompilation/Images/jetson/usr/local/lib/libprotobuf.so: undefined reference to `inflate'
/home/lhahn/Documents/CrossCompilation/Images/jetson/usr/local/lib/libprotobuf.so: undefined reference to `inflateInit2_'
/home/lhahn/Documents/CrossCompilation/Images/jetson/usr/local/lib/libprotobuf.so: undefined reference to `inflateEnd'
collect2: error: ld returned 1 exit status
make[2]: *** [CMakeFiles/Test.dir/build.make:98: Test] Error 1
make[1]: *** [CMakeFiles/Makefile2:83: CMakeFiles/Test.dir/all] Error 2
make: *** [Makefile:91: all] Error 2
The required library (ZLIB) exists in my sysroot (/home/lhahn/Documents/CrossCompilation/Images/jetson/usr/lib/aarch64-linux-gnu/libz.so), but the linker can't find it.
My toolchain file is
set(CMAKE_SYSTEM_NAME Linux)
set(CMAKE_SYSTEM_PROCESSOR aarch64)
set(CMAKE_SYSROOT /home/lhahn/Documents/CrossCompilation/Images/jetson)
set(CMAKE_C_COMPILER /home/lhahn/Documents/CrossCompilation/gcc-linaro-7.3.1-2018.05-x86_64_aarch64-linux-gnu/bin/aarch64-linux-gnu-gcc)
set(CMAKE_CXX_COMPILER /home/lhahn/Documents/CrossCompilation/gcc-linaro-7.3.1-2018.05-x86_64_aarch64-linux-gnu/bin/aarch64-linux-gnu-g++)
set(CMAKE_FIND_ROOT_PATH /home/lhahn/Documents/CrossCompilation/Images/jetson)
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)
What do I need to tell CMake so that the linker can find these secondary dependencies?

Answer 1

I figured out my problem. When I cloned the image and mounted it on my laptop I broke all of the symlinks in the cloned image, such as libz.so which is why cmake couldn't find them. When I fixed the symlink cmake went on to complain about the next broken symlink in the same manner. I think there are too many symlinks to fix them manually, but at least now I know what went wrong.