Jetson newcomer, trying to work it all out

My suggestion is that you add those libraries on the Jetson itself. Then either clone again, or simply use rsync to update the loopback mounted clone over ssh . Then it won’t matter if the libraries are being looked for in a default location versus an exact location.

By the way, what is the difference between using rsync to “update the loopback mounted clone” and just using rsync to update the lib, usr/include and usr/lib folders so that they match what is on the Jetson? I.e. why do I need to clone/mount at all?

I don’t have an exact answer, but I’ll spit out a few details that are probably related.

The crt*.o files are statically linked, and they are the ones which provide all of the “non-bare-metal” behavior. Things like C automatic allocation of local variables does not exist on true bare metal. Those particular files are a fundamental part of every C and C++ program at the system level. The rpath might demand the files be in the same subdirectory when your program is copied somewhere else. If the sysroot is properly named such that the cross tools know about the “offset” the mount point of the sysroot causes, then the final program should work correctly without being bound to a specific absolute path the way rpath might bind. Properly setting up a sysroot for cross compile should allow any cross tool to find the files without special effort.

Regarding rsync, symbolic links might be an issue when used as a sysroot. Note that many symbolic links are relative path, and others are absolute path. The absolute path would be copied as absolute path, and if the file is now in a subdirectory of “/home”, then that absolute path will still point to something in “/” which is the host’s file and not the sysroot file. For cloning this is a good thing, because it means when the clone is restored to its original location the absolute path is correct; however, while on the sysroot, this will be incorrect unless the cross tools have that understanding of a sysroot mount point.

If you have a pure clone image, and mount it somewhere, then the file content is no different versus having done so with rsync, but there can be differences. First, a true clone only clones the physical device. rsync would normally be told to not cross filesystems, but it can if told to. dd and Jetson clone cannot cross filesystems.

As an illustration, “/proc”, “/sys”, and much of “/dev” will be different filesystems. They are not ext4. Just cd to one of those locations, and check the filesystem type with “df -H -T”. They won’t be ext4. You might have some files in “/dev” on the actual filesystem, so you wonder how can this not be ext4? It’s because the pseudo filesystem is mounted over the ext4 filesystem. As soon as the dev filesystem is unmounted, the original files show up again. A dd clone will show the files that exist without the “/ddev” mount, even if “/dev” is mounted, because it is running at the block device level. rsync is running at the filesystem level, and no file in “/dev” would be copied if not told to cross filesystems. Furthermore, rsync cannot copy files in the underlying ext4 of “/dev” without unmounting of “/dev”'s pseudo filesystem. Note that “/dev”, “/proc”, and “/sys” do not exist on any block device, they live entirely in RAM, and are a figment of some driver’s imagination! Without the driver, neither the pseudo filesystem, nor the files within them, can exist.

rsync cannot copy content covered by another filesystem. dd can. For dd to copy the “/dev” content which is not on the original ext4 filesystem it would have to be told to copy that other block device, and that block device only exists after mounting it. You do not normally want to copy any pseudo filesystem.

Within any actual filesystem directory, e.g., “/lib” or “/usr/lib” or “/home”, there is no difference between the result of a dd/clone copy and an rsync copy. If this was originally a clone, and you updated the clone source, and then updated the clone via rsync of the clone source, then the two should once again be exact matches so long as we are not crossing filesystems and not copying content hidden by some other mount on top of it. A clone takes a lot of time though, and an rsync of a system to a clone with minor updates is fast and easy. Whichever is more convenient when making updates is what you use.

There is an advantage at times to cloning everything and then loopback mounting as a sysroot. You don’t always know what you are going to need. Building against a full clone guarantees that any requirements exist on the real destination machine. You can use just rsync, but then you won’t have a backup if something goes wrong, and a full clone is by far the most thorough backup you can get.

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.