Marton Balint (2018-02-23): > The environment variable contains the directory to the library, not the > library name itself.
So it reinvents LD_LIBRARY_PATH. Probably badly. > LD_LIBRARY_PATH, LD_PRELOAD is an environment variable as well, so I don't > see why it is different from security standpoint. It is not different in concept, but the details were designed by very competent hackers. Yet, over the years, numerous security issues related to these features have been found and fixed. > 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. I had not yet thought of it. This is worrisome. > I'd rather say that we should add 100+ lines of code because: > - it fixes some portability issues with the library names So, in order to fix the portability issues of this library, any application that uses it is supposed to implement these 100+ lines of code. I say: let them fix their crap. > - dynamic loading alone has some pros (e.g. not needing the SDK > on every machine where you use your built ffmpeg) Sorry, you are wrong, this is not how dynamic loading works. You need the shared library (and possibly supporting data files), whether you load it through dlopen() or through NEEDED. > - we can use the SDK suggested way to find the library using an > environment variable Let them fix their crap. > - the author who is the de facto maintainer prefers it this way Let them fix their tastes. > I also tried to help making the code "less ugly" in my review. Les ugly is still ugly. Regards, -- Nicolas George
signature.asc
Description: Digital signature
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
