I am doing cross compile on x86 for aarch64. I clone the Xavier and mounted clone.img.raw on jetson folder
so the xavier filesystem is in jetson folder
and then, I use cmake to build the code
the cmake configuration is like below
# the name of the target operating system
set(CMAKE_SYSTEM_NAME Linux)
set(CMAKE_HOST_SYSTEM_NAME Linux)
set(CMAKE_SYSTEM_PROCESSOR aarch64)
set(CMAKE_C_COMPILER home/username/gcc-linaro-7.3.1-2018.05-x86_64_aarch64-linux-gnu/bin/aarch64-linux-gnu-gcc)
set(CMAKE_CXX_COMPILER home/username/gcc-linaro-7.3.1-2018.05-x86_64_aarch64-linux-gnu/bin/aarch64-linux-gnu-g++)
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} --sysroot=/home/username/jetson" CACHE INTERNAL "" FORCE)
set(CMAKE_CXX_LINK_FLAGS "${CMAKE_CXX_LINK_FLAGS} --sysroot=/home/username/jetson " CACHE INTERNAL "" FORCE)
set(CMAKE_FIND_ROOT_PATH /home/username/jetson
home/username/gcc-linaro-7.3.1-2018.05-x86_64_aarch64-linux-gnu)
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)
I use find_package to find opencv and when I cmake and make the code, the output is
[100%] Linking CXX executable testing
/home/username/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: cannot find -lcuda
collect2: error: ld returned 1 exit status
-lcuda is libcuda.so and this shared library exists in jetson folder(/home/username/jetson/usr/lib/aarch64-linux-gnu).
I deduce the cross linker ld want to find libcuda.so but the path is not included in ld’s SEARCH_DIR
I check SEARCH_DIR of ld
Hi,
I apply these commands on the x86 host but I assign the direction to folder mounted by clone.img.raw
called jetson(clone filesystem from Xavier)
therefore, the result like below
and I found /jetson/usr/local/cuda is a broken link
jetson/etc/alternatives/cuda is linked to /usr/local/cuda-10.2(on x86 host)
I hope cross compiler and its linker can use aarch64 cuda directly from the jetson folder mounted by clone.img.raw
and will it be a problem and how to solve it?
The symbolic links might be wrong after mounting a clone somewhere else. It just depends. If the symbolic link is a relative path, then it is usually correct; if the symbolic link is an absolute path, then the clone mount is likely wrong. You could convert the symbolic link from absolute to relative if this is the issue.
To see the content of what the link itself points at use “ls -l” on the full path. Example, if the mount point is “~/jetson”:
ls -l ~/jetson/usr/local/cuda
ls -l ~/jetson/etc/alternatives/cuda
Let’s pretend that you now have this (adjust for your case): ~/jetson/usr/local/cuda -> /etc/alternatives/cuda/
If you cd to “~/jetson/usr/local/”, then you could convert this to a relative path if the absolute path is wrong:
cd ~/jetson/usr/local
# Method one, absolute path, but adjusted:
sudo ln -sf ./cuda ~/jetson/etc/alternatives/cuda
# Now verify it points to the next location:
ls -l ./cuda
# BETTER choice, convert to relative path so any mount point works:
cd ~/jetson/usr/local
sudo ln -sf ./cuda ../../etc/alternatives/cuda
# Verify:
ls -l ./cuda
Each “../” implies go up to one parent directory. From “~/jetson/usr/local”, the “../” is the same as “~/jetson/usr”; then “../../” is “~/jetson”, and “../../etc/alternatives” is “~/jetson/etc/alternatives”, but the relative path method will remain correct no matter where you mount the clone image.
If “~/jetson/alternatives/cuda” also points to an absolute path, then you’d do the same thing there until all relative paths point to actual content.