This ALMOST works, but not quite. I managed to get VTK to compile but had to mess with one of the link.txt files manually to set rpath to include my toolchain directories. With PCL I am having even worse problems such as:
/opt/gcc-aarch64-unknown-linux-gnu/bin/../lib/gcc/aarch64-unknown-linux-gnu/4.8.5/../../../../aarch64-unknown-linux-gnu/bin/ld: warning: libbz2.so.1.0, needed by /opt/gcc-aarch64-unknown-linux-gnu/aarch64-unknown-linux-gnu/sysroot/usr/lib/aarch64-linux-gnu/libboost_iostreams.so, not found (try using -rpath or -rpath-link)
/opt/gcc-aarch64-unknown-linux-gnu/bin/../lib/gcc/aarch64-unknown-linux-gnu/4.8.5/../../../../aarch64-unknown-linux-gnu/bin/ld: warning: libz.so.1, needed by /opt/gcc-aarch64-unknown-linux-gnu/aarch64-unknown-linux-gnu/sysroot/usr/lib/aarch64-linux-gnu/libboost_iostreams.so, not found (try using -rpath or -rpath-link)
/opt/gcc-aarch64-unknown-linux-gnu/bin/../lib/gcc/aarch64-unknown-linux-gnu/4.8.5/../../../../aarch64-unknown-linux-gnu/bin/ld: warning: libicui18n.so.55, needed by /opt/gcc-aarch64-unknown-linux-gnu/aarch64-unknown-linux-gnu/sysroot/usr/lib/aarch64-linux-gnu/libboost_regex.so, not found (try using -rpath or -rpath-link)
/opt/gcc-aarch64-unknown-linux-gnu/bin/../lib/gcc/aarch64-unknown-linux-gnu/4.8.5/../../../../aarch64-unknown-linux-gnu/bin/ld: warning: libicuuc.so.55, needed by /opt/gcc-aarch64-unknown-linux-gnu/aarch64-unknown-linux-gnu/sysroot/usr/lib/aarch64-linux-gnu/libboost_regex.so, not found (try using -rpath or -rpath-link)
/opt/gcc-aarch64-unknown-linux-gnu/aarch64-unknown-linux-gnu/sysroot/usr/lib/aarch64-linux-gnu/libboost_filesystem.so: undefined reference to `std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::find_first_not_of(char const*, unsigned long, unsigned long) const@GLIBCXX_3.4.21'
/opt/gcc-aarch64-unknown-linux-gnu/aarch64-unknown-linux-gnu/sysroot/usr/lib/aarch64-linux-gnu/libboost_regex.so: undefined reference to `std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::compare(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&) const@GLIBCXX_3.4.21'
/opt/gcc-aarch64-unknown-linux-gnu/aarch64-unknown-linux-gnu/sysroot/usr/lib/aarch64-linux-gnu/libboost_regex.so: undefined reference to `u_digit_55'
/opt/gcc-aarch64-unknown-linux-gnu/aarch64-unknown-linux-gnu/sysroot/usr/lib/aarch64-linux-gnu/libboost_system.so: undefined reference to `std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::_M_create(unsigned long&, unsigned long)@GLIBCXX_3.4.21'
What am I missing, or what did I do wrong? This seems like it should be much easier than it has been.
ld: warning: libbz2.so.1.0, needed by
ld: warning: libz.so.1, needed by
ld: warning: libicui18n.so.55, needed by
ld: warning: libicuuc.so.55, needed by
The linker involved is the arm64/aarch64 cross linker, so the libraries mentioned need to be the arm64/aarch64 version. Either the arm64 libraries needed don’t exist, or you did’t tell your linker where to find them. It is easy to cross compile software which doesn’t link to anything else, but once you link you must provide everything the cross linker asks for.
For your case I can’t say what option is needed to name a library linker search path (though it’ll probably be in a subdirectory of the sysroot), but this is what you should research. Once you know that, then you can see if the arm64 libraries are there. If you know the libraries exist, then just edit this path to include where the libs are; if not, then add the libs.
FYI, if you have installed all of the dev packages needed to build this software on the Jetson, then a clone or direct file copy can be used as a source of those files. You don’t have to actually build on the Jetson, but the Jetson’s native package manager will have many things available to it which your PC won’t have without building it yourself.
That’s the thing, they do exist, in the directories specified in my CMAKE_LIBRARY_PATH, which are all relative to the sysroot I have set. Was wondering if my cmake file was missing anything, or if I’m just going to have to perform surgery to get this to cross compile.
Thanks, that is actually how I constructed my sysroot. I was hoping that I had missed something obvious in my cmake setup, but I am starting to suspect it is more a question of each cross compile being fraught with its own problems. Is there a guide anywhere to cross compiling using cmake for the Jetson?
Details would be needed. If you can post a log that would help due to knowing specific libraries. Running “file” on each of the files involved to see if they are the correct architecture would help as a starting point.
When you set the variable CMAKE_SYSROOT for your target’s root file system, it is supposed to pass the -sysroot= to the linker (which it does successfully). Unfortunately, the linker seems to ignore this and still by default search your rootfs for library dependencies.
For example: I have an executable which tries to link with library libopencv_core.so which in turn links against libz.so.1. The linker tries to find libz.so.1 in the develop system’s root level directories rather than the sysroot…
Do you have a log line which shows the specific path being searched? There are basically two themes possible. One is to name a sysroot for everything (and then for example you could use a mounted clone image of the Jetson), or to use the default paths, but with architecture in the name of the path.
In the latter form consider that your base operating system might have:
If you don’t have an entire filesystem root path, then you’d need the architecture specific path in each of the “/usr/lib/”, “/lib/”, or any other requested specific subdirectory (in which case if the host PC does not have those available by package I simply use a symbolic link to the correct location of a loopback mounted clone…then I just mount a different clone if I need a different release…but a recursive copy would also work).
Thus the question about logs…to know exactly where it is searching. Perhaps you need an architecture specific directory added.
Well, I did have a clone of the root filesystem for the target planted on my develop machine. I set the CMAKE_SYSROOT to that path. However, the linker would not find certain files. I did make symbolic links in my developer root with the architecture name.
For example: I made the symbolic links
/lib/aarch64-linux-gnu point to //lib/aarch64-linux-gnu
/usr/lib/aarch64-linux-gnu point to //usr/lib
The 2nd link did not really help anything that I know of. I can remove the link and the build is fine.
The main problem I have, is that if I explicitly link to OpenCV’s library (which will need link to something linke libz.so.1) the linker will not properly link to libz.so.1. Instead, I have to manually add ‘z’ to target_link_libraries() and then it links just fine, no complaints. I have to do this for every library OpenCV requires dynamic linking to, which is quite the pain.
Most commands which are given on command line can be logged like this:
some_command 2>&1 | tee log.txt
It is possible that the command has already redirected the error stream (the “2”), in which case perhaps logging might not be as expected, but give it a try like the above lists.
If you hover your mouse over the quote icon in the upper right of one of your existing posts, then other icons will show up. The paper clip icon is for attaching files.