L4T 35.1 libcudart not included. Why?

Hi Nvidia L4T users –

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’d like to be clear on this.

Thanks.

cudart is provided by another package:

sudo apt search cudart
Sorting... Done
Full Text Search... Done
cuda-cudart-11-4/stable,now 11.4.243-1 arm64 [installed,automatic]
  CUDA Runtime native Libraries

cuda-cudart-dev-11-4/stable,now 11.4.243-1 arm64 [installed,automatic]
  CUDA Runtime native dev links, headers

that installs libs into /usr/local/cuda-11.4/targets/aarch64-linux/lib (for CUDA 11.4):

ls /usr/local/cuda-11.4/targets/aarch64-linux/lib/libcudart*
/usr/local/cuda-11.4/targets/aarch64-linux/lib/libcudart.so
/usr/local/cuda-11.4/targets/aarch64-linux/lib/libcudart.so.11.0
/usr/local/cuda-11.4/targets/aarch64-linux/lib/libcudart.so.11.4.243
/usr/local/cuda-11.4/targets/aarch64-linux/lib/libcudart_static.a

Correct @Honey_Patouceul.

The question is why is libcudart omitted from the L4T 35.1 list of packages installed on the Xavier/Orin target by apply_binaries.sh?

Is the normal practice to statically link to libcudart_static.a in a cross environment and then not install libcudart.so on the embedded 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.

@Honey_Patouceul

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.

You may also see:

Hi,

CUDA runtime is a user space library.
You can install via apt.

https://repo.download.nvidia.com/jetson/

Thanks.

If repositories are set up, see what you get from this on the running Jetson:
apt search cudart

Related:
sudo apt-get install <package name>

@linuxdev @AastaLLL

Thank you both.

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 ;-)

Hi,

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.

Thanks.

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