Description
The latest release notes page includes the following message:
TensorRT 11.0 is coming soon with powerful new capabilities […]
Breaking packaging changes that may require updates to your build and deployment scripts:
[…]
Static libraries on Linux (libnvinfer_static.a, libnvonnxparser_static.a, etc.) are deprecated starting with TensorRT 10.11 and will be removed in TensorRT 11.0. Migrate to shared libraries.
It is not a big deal for containerized workloads, but a bit more complicated for SDK products which now would have to depend on TensorRT. Currently, it is possible to link with TensorRT staticly to avoid dealing with TensorRT distribution on the customer side.
Do public repositories (ie DEB, RPM) for TensorRT exist or planned for the future? It would be really helpful to plug in such a repository and get all dependencies fetched automatically. As far as I can tell, such repositories exist for TensorRT JetPack distributions, so it seems doable.
@athkumar Hello! Should we expect a comment any time soon? It seems that the topic is being ignored.
Hi @sergeev917 ,
Apologies for the late response.
Thank you for reaching out and for detailing your use case.
I am escalating this directly to our internal TensorRT product and packaging teams to check if there are any current plans or roadmaps for public DEB/RPM network repositories for standard Linux distributions.
I will update this thread as soon as I have a concrete answer or guidance from the team. Thank you for your patience!
Hello @athkumar!
Thank you, we will be waiting for updates!
Just as a side note – Docker images with pre-installed TensorRT packages are already publicly available [1], so it is technically possible to reconstruct TensorRT DEB packages with dpkg-repack. This gives us the impression that there is no active goal to place these packages behind a login page. Looking at [2], it seems that a public TensorRT repository will be helpful for CI and unification purposes.
[1] For example: Image Layer Details - nvidia/cuda:13.0.0-tensorrt-devel-ubuntu24.04
[2] dist · master · nvidia / container-images / cuda · GitLab
Hello @sergeev917 ,
Apologies for keeping you waiting !
To address your questions directly:
Public Repositories for TensorRT
Public DEB and RPM repositories for TensorRT do exist and are actively maintained. You do not need to reconstruct them from Docker images.
- They are hosted alongside the CUDA repositories here: Index of /compute/cuda/repos
- Once the CUDA network repository is configured, you or your customers can fetch TensorRT and its dependencies automatically using standard package managers (e.g.,
apt install tensorrt or dnf install tensorrt).
Context on Removing Static Libraries
TensorRT Team announced the deprecation of static libraries (like libnvinfer_static.a) about 10 months ago. The primary reason for their removal is file size bloat.
TensorRT’s static library had grown to ~7GB, which heavily inflated our distribution tarfiles and directly bloated any customer applications statically linking to it. In addition, the resources required to build and test these oversized libraries became too significant to maintain. Transitioning to shared libraries significantly reduces the footprint for both our distribution and your final compiled applications.
There will be some changes required to adapt, yes !
Hello @athkumar!
Thank you for the response! TensorRT libraries are indeed available in the CUDA repositories, so we will start relying on them.
Not sure I follow. TensorRT code remains virtually the same regardless of it being shipped as a static library or a shared library. Some unused functions might be pruned during linking into a shared library (TensorRT), but the same logic applies for the final linking into an application executable that uses TensorRT static libraries – unused functions are going to be pruned as well.
Actually, static libraries might cause less bloat for customer applications – for example, depending on the application a customer might link for a particular GPU architecture (arch=sm_…/compute_…), thus allowing to drop unnecessary implementations for other architectures during linking with a static library – which is impossible with shared libraries which are shipped as-is and cannot be modified. I think it is safe to assume that size bloat was the issue behind TensorRT dropping dependency on cuDNN and it did not help that there were cuDNN shared libraries.
Instead, I see the following issues with static libraries:
- Growing size of static libraries might cause eventual linking failures – as the overall size grows beyond 4GB it is more and more likely to trigger x86 code relocation failures due to reliance on 32-bit offsets.
- Shared libraries allow to delay implementation loading for optional features. I assume this is the idea behind separating Windows-compatible builder for Linux into its own libnvinfer_builder_resource_win.so library. I suppose the main benefit of this is to avoid shipping unused components altogether, as code loads on per-page on-demand basis anyway. This can also be done to some degree with static libraries (by linking either with a proper or stub implementation), but surely less pleasant.
- Publishing both shared and static libraries obviously cost 2x storage (for the publishing party).
- Shared libraries can be put into public Nvidia repositories, so we do not have to ship the same volume of code linked into our applications. This makes no difference for our customers – they are going to fetch similar volume of data, just from different sources. But it surely reduces burden on our distribution.