Need static version of the Deepstream sdk plugins to enable use of statically compiled GST

Please provide complete information as applicable to your setup.

• Hardware Platform (Jetson / GPU)
Jetson nano dev kit

• DeepStream Version
DS 6.0

• JetPack Version (valid for Jetson only)
4.6

• TensorRT Version
8.0.1.6

• NVIDIA GPU Driver Version (valid for GPU only)
Cuda toolkit version: 10.2.300

• Issue Type( questions, new requirements, bugs)
Question:

Does nVidia plan to publish static version (.a) of the nvd* shared libs present in the DS sdk ? if yes, when could it be expected ?

deepstream nvds*.so libraries are referencing libgst*.so and it prevents someone from using his own version of gst (statically linked).

I’ve successfully statically cross-compiled gstreamer and I’m running it on Jetson nano (using wsl2, vcpkg, dedicated toolchain and several port fixes).
I’m now trying to leverage the deepstream plugins to benefit from gpu/hw acceleration.

Since there are no source-code access I’m aware off for these (?), I can’t generate the .a version of the various libnvds_* libraries. Hence the need to have nVidia releasing the .a version along with the .so version of the various libraries included in the DS sdk (or provide the sources).

PS: I’m conscious that gst plugins model is not ideal for static compilation, nonetheless, current lack of .a files from the DS sdk libraries forces me to use a shared lib version of the gst.

• How to reproduce the issue ? (This is for bugs. Including which sample app is using, the configuration files content, the command line used and other details for reproducing)
Trying to create deepstream_test1 statically linked against deepstream 6.0 plugins & static version of gst.

• Requirement details( This is for new requirement. Including the module name-for which plugin or for which sample application, the function description)
Provide *.a files along with the various .so files so one can statically compile deepstream_test1 against nvds and gstreamer (static version of gst).

No. Why we really need it?

Why we really need it?

It would provide possibility to increase overall level of security (for developers/products that require it).

Current nv-ds lib mode mandates one to use shared version of gst (and all associated plugins) & openssl … meaning larger surface of attack from exposed APIs.

With static libs => single large app (and very few system/drivers so libs dependencies) => reduced number of APIs to strengthen => increased security level.

My current sw setup is (roughly):
dlib19.22(dnn,cuda) + ffmpeg(cuda/nvcodec) + opencv3.4 + caf0.18 + openssl1.1.1m + gst1.19.2 + boost1.78 + flatbuffers2.0 + curl7.8 + spdlog1.9 + nlohmann-json3.10 + rocksdb6.27 + protobufs3.18 + libvisionworks1.6 + …
=>
that is currently running on Jetson nano as 1 single statically linked 50MB app (only relies on system & drivers so libraries).

I’m willing to add DS to the mix (and get rid of dlib & tf) but having to put back gst & openssl as shared-lib is an invite for security pbs I’d prefer to avoid in first place.

No. We do not provide such functions.

nVidia provides static version of its libraries for pretty much everything else… cuda, tensorrt, etc…
What makes DeepStream different ?

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