Could someone explain why libcudart isn’t packaged as part of the L4T 35.1 release?
I’ve searched the packages installed by apply_binaries.sh, and clearly libcudart is not included. Below is a bash one-line script to search the L4T supplied nvidia packages.
I’ve had to install libcudart from the upstream Nvidia CUDA Debian package repos. Having a bifurcated CUDA install on a Xavier or Orin target – from two different places – isn’t making a lot of sense. Could someone explain this to me?
We need libcudart as part of our application. Ideally, this should be included as part of the L4T release.
$ pwd
/sdk_35.1.0/Linux_for_Tegra/nv_tegra/l4t_deb_packages
for i in *; do \
if ( dpkg -c $i | grep libcudart); then \
echo $i; \
break; \
fi; \
done
$ ls
nvidia-l4t-3d-core_35.1.0-20220810203728_arm64.deb
nvidia-l4t-apt-source_35.1.0-20220810203728_arm64.deb
nvidia-l4t-camera_35.1.0-20220810203728_arm64.deb
nvidia-l4t-configs_35.1.0-20220810203728_arm64.deb
nvidia-l4t-core_35.1.0-20220810203728_arm64.deb
nvidia-l4t-cuda_35.1.0-20220810203728_arm64.deb
nvidia-l4t-firmware_35.1.0-20220810203728_arm64.deb
nvidia-l4t-gbm_35.1.0-20220810203728_arm64.deb
nvidia-l4t-gputools_35.1.0-20220810203728_arm64.deb
nvidia-l4t-graphics-demos_35.1.0-20220810203728_arm64.deb
nvidia-l4t-gstreamer_35.1.0-20220810203728_arm64.deb
nvidia-l4t-init_35.1.0-20220810203728_arm64.deb
nvidia-l4t-initrd_35.1.0-20220810203728_arm64.deb
nvidia-l4t-jetson-io_35.1.0-20220810203728_arm64.deb
nvidia-l4t-jetsonpower-gui-tools_35.1.0-20220810203728_arm64.deb
nvidia-l4t-libvulkan_35.1.0-20220810203728_arm64.deb
nvidia-l4t-multimedia_35.1.0-20220810203728_arm64.deb
nvidia-l4t-multimedia-utils_35.1.0-20220810203728_arm64.deb
nvidia-l4t-nvfancontrol_35.1.0-20220810203728_arm64.deb
nvidia-l4t-nvpmodel_35.1.0-20220810203728_arm64.deb
nvidia-l4t-nvpmodel-gui-tools_35.1.0-20220810203728_arm64.deb
nvidia-l4t-nvsci_35.1.0-20220810203728_arm64.deb
nvidia-l4t-oem-config_35.1.0-20220810203728_arm64.deb
nvidia-l4t-openwfd_35.1.0-20220810203728_arm64.deb
nvidia-l4t-optee_35.1.0-20220810203728_arm64.deb
nvidia-l4t-pva_35.1.0-20220810203728_arm64.deb
nvidia-l4t-tools_35.1.0-20220810203728_arm64.deb
nvidia-l4t-vulkan-sc_35.1.0-20220810203728_arm64.deb
nvidia-l4t-vulkan-sc-dev_35.1.0-20220810203728_arm64.deb
nvidia-l4t-vulkan-sc-samples_35.1.0-20220810203728_arm64.deb
nvidia-l4t-vulkan-sc-sdk_35.1.0-20220810203728_arm64.deb
nvidia-l4t-wayland_35.1.0-20220810203728_arm64.deb
nvidia-l4t-weston_35.1.0-20220810203728_arm64.deb
nvidia-l4t-x11_35.1.0-20220810203728_arm64.deb
nvidia-l4t-xusb-firmware_35.1.0-20220810203728_arm64.deb
Might answer my own question here, but other people please chime in.
Is the general, recommended practice for CUDA applications to statically link to libcudart_static.a and thus avoid the need to install libcudart.so on the Xavier/Orin target?
I think it’s just installed as a dependency (of cuda-libraries-11.4, itself installed as a dependency of …).
Not sure what is your concern, but I might not be able to further help.
If you flash a Xavier or Orin using the L4T 35.1 flash.sh tools from the command line, using a minimalistic, reduced size rootfs built from scratch, the target will not have libcudart.so.
From what I understand, CUDA is broken in two big blocks or groups:
1/ The “drivers”, which get installed on a Xavier or Orin aach64 target , and,
2/ The “host” build and runtime environment, typically used on x86_64, which can include cross tools for aarch64.
How are “normal” CUDA applications expected to be cross-compiled to aarch64 on x86_86 so they can be deployed to a Xavier or Orin target? As libcudart isn’t part of the normal “drivers” install on the target, is the CUDA application expected to be statically linked to libcudart_static.a? Are additional libraries needed to be statically linked?
Or put the other way around, what is Nvidia’s reasoning for omitting libcudart from the L4T 35.1 list of installed CUDA packages?
From what I can gather, many developers don’t use the “drivers” API but rather the runtime API in libcudart. That’s problematic as libcudart isn’t installed on the Xavier/Orin targets by default using the L4T 35.1 flash.sh tools.
This might be out of my skills that I can share.
I have poor experience of your case.
There are post-flash steps (including first boot) that may install some packages.
You may clone the jeston linux rootfs after that and check differences.
This is a CUDA software product build and deployment question. What’s the canonical way to build a CUDA executable that gets deployed to a Jetson target? A minimalistic rootfs won’t have any of the runtime CUDA packages after flashing with L4T flash.sh. Do CUDA executables employ static linking to runtime CUDA libraries as a general rule?
And don’t forget, with Orin you need to pass new arch gencode parameters to nvcc ;-)
We don’t include the CUDA library in the L4T since it is a user-space library.
But you should be able to link it statically or dynamically after the apt installation.