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

[sylvain.prevost]

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

[kesong]

No. Why we really need it?

[sylvain.prevost]

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.

[Fiona.Chen]

No. We do not provide such functions.

[sylvain.prevost]

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