[FFmpeg-devel] [PATCH] configure: support static libnpp [v2]

[Hendrik Leppkes]

On Fri, Jun 2, 2017 at 11:56 AM, Andreas Håkon
<andreas.hakon at protonmail.com> wrote:
> Hi Hendrik,
>
> I don't like that there is a separate configure option. We can link to
> other libraries dynamically or statically depending on what is found,
> without needing two configure options per library.
>
> I understand. However, this is not really true for libnpp*.
> Let me to explain about this special case:
>
> If you like to compile FFmpeg statically you can do it. However, you link all or none.
> And in the case of libnpp* if you link with regular shard objects, then you need to have all CUDA SDK libraries installed in your computer.
> However, if you link to the static version of this library then you need to install only the NVidia driver.
>
> The trick is the dynamic loading of the library "libcuda.so.1" in the source code of the "dynalink_loader.h".
> Please, review my description about this special case at: http://trac.ffmpeg.org/ticket/6405
>
> So, this patch simplifies a lot the use of the libnpp functions (like the 'scale_npp').
> More or less, is similar to the use of "nvenc_*" in FFmpeg. By default it doesn't link dynamic with CUDA, as the "dynalink_loader.h" has the code to load the functions from the shared library provided by the DRIVER, not the CUDA lib (the shared object "libcuda.so.1" is provided by the DRIVER, and not by the SDK).
> In fact, the CUDA shared library is a mere wrapper to load some functions. These functions can be in shared objects or in static libraries.
> Then, if you like to compile a regular FFmpeg with shared objects and dependent to the NVidia DRIVER, but not with the CUDA SDK, you can use this patch.
>
> I hope you agree this explanation. This patch is really useful.
>

I don't dispute that static linking might be useful, but I'm still not
liking needing a separate configure option, if perhaps another
solution can be found.

However, one thing to remember is that you need to build FFmpeg as
non-free for this, so you are not allowed to distribute these
binaries. So one might argue that when you need the CUDA SDK during
build time, and you cannot distribute these binaries, then what
advantage is there?

PS:
Please don't top post on this mailing list.

- Hendrik