[FFmpeg-devel] [PATCH 2/2] Implement dynamic loading of NewTek NDI library
cus at passwd.hu
Fri Feb 23 02:32:59 EET 2018
On Thu, 22 Feb 2018, Nicolas George wrote:
> Marton Balint (2018-02-22):
>> I think what CE ment was static v.s. dynamic lib names
> I am pretty sure he asked if the file name of the library could be
> different at run time than at compile time, which would be the only
> reason to justify using an environment variable.
The environment variable contains the directory to the library, not the
library name itself.
> By the way, using an environment variable to load a dynamic library is a
> terrible idea in terms of security. Let us not do it.
LD_LIBRARY_PATH, LD_PRELOAD is an environment variable as well, so I don't
see why it is different from security standpoint.
And it's not unprecedented, there is FREI0R_PATH, or LADSPA_PATH for
example. Okay, these are plugins, so not entirely the same thing, yet the
approach is similar.
>> With dynamic loading we can rely on the library name defined in the NDI SDK
>> headers which should be the proper one for each OS/arch.
> So basically, we should add 100+ lines of ugly code just because these
> guys are unable to follow the same rules as any other library?
I'd rather say that we should add 100+ lines of code because:
- it fixes some portability issues with the library names
- dynamic loading alone has some pros (e.g. not needing the SDK
on every machine where you use your built ffmpeg)
- we can use the SDK suggested way to find the library using an
- the author who is the de facto maintainer prefers it this way
I also tried to help making the code "less ugly" in my review.
More information about the ffmpeg-devel