Packages for the wrong architecture will not install on the host PC, and the Jetson’s architecture is wrong for a PC. You have to install the PC version on the PC. Cross compile and cross development is a special case, and does not install in the usual way.
On a PC used for cross development you will have a toolchain which is a cross toolchain…that chain executes on PC architecture, but understands the arm64/aarch64/ARMv8-a code. This is simple for bare metal as there is no linker involved, and no libraries needed to link against. Cross toolchains are often available through the host PC’s native package tools since the PC can run the executable. Linaro also provides some of these.
If you want to link against a library in a cross development environment, then you need a “runtime” linker, and this linker is special. The cross linker (“runtime”), like the cross toolchain, runs on PC architecture, but works with 64-bit arm64/aarch64/ARMv8-a code. The host o/s cannot use the linked code, but it can perform a link. Cross linker runtime tools are often available through the host PC’s native package tools since the PC can run the executable. Linaro also provides some of these.
The code which the cross linker/runtime links against is purely 64-bit arm64/aarch64/ARMv8-a, and the host can never use this. Thus the host will refuse to install this as a normal library to be searched for in its own linker path. This is the “sysroot”, and is basically a skeleton of the libraries and library related content copied directly from the Jetson (or any 64-bit arm64/aarch64/ARMv8-a compatible version).
“Sysroot” libraries make life much more difficult and are where it gets complicated. Linaro and some other providers have available a very bare minimum environment, including libc and perhaps a tiny subset of what you might find on a fully running system. That content is enough to build other content, but we are talking about building everything. Often, to build some basic and simple library which your application uses there will be perhaps up to a hundred other packages you must build first. Libraries often link to other libraries, and so there is this big recursive dependency all the way back to libc. If just one of those touches X11, then you’ll probably end up building many hundreds of side projects just to get to the point where you can cross compile and link your simple program.
However, there is a shortcut around this. You can copy the content from a running Jetson if that content was installed there. You’d want to install the development packages with header files, and not just the libraries. After this you can either recursively copy the right library structures into your host PC within the correct directory for aarch64 to prevent mixing with the PC content, or you can clone the rootfs and loopback mount the clone. One can name the clone or a symbolic link to the clone without much effort, and suddenly you have the entire Jetson library support using the exact version of library the Jetson itself has.
Note that a clone can be mounted read-only, and that this is often not an issue for use in a cross development environment. SDK Manager provides arm64/aarch64 packages which can only install on the Jetson, and virtually nobody will provide those for install onto a PC. This isn’t to say you can’t do it, but unless you are an expert at this the odds are you’re just going to mess up your PC and complicate your life with a foreign architecture. After you go through all of that effort you will find that the libraries are the wrong version, or that one of the niche packages on the Jetson is not available that way.
You can also run a QEMU environment and install arm64/aarch64/ARMv8-a packages in this since the environment truly is not PC, but you run into the same issues of perhaps not having the Jetson’s version of those packages available, or having other issues.
For your locked root filesystem, is this basically a clone of the Jetson? If so, then you can probably name the path to the
aarch64 files there as your sysroot. If this is an actual clone I consider it better, because then you can loopback mount it. If you have files directly copied to your system, then you have to either erase them or make different locations whenever a version changes. With a clone you name the aarch64 sysroot with a symbolic link, and when you loopback mount this, you magically get that exact and entire environment. If you have four versions and four clones, a loopback sysroot is trivial to switch between them in a matter of seconds.