[FFmpeg-devel] [RFC] Support dynamic loading of third-party libs
Reimar Döffinger
Reimar.Doeffinger at gmx.de
Fri Jan 16 16:43:37 CET 2015
On Wed, Jan 14, 2015 at 06:26:06PM +0100, Michael Niedermayer wrote:
> ive no idea how portable it is but one way to avoid most of the
> mess would be to use attribute weak / lazy linking
> that way as long as lib functions arent called nothing should try to
> load the lib and so it should work with unresolved references
>
> something like dlopen would need to be used to detect if the
> lib is available or not before registering the lib wraper
>
> if that would work it should be alot cleaner / require significantly
> less code per lib, but its quite possible that this simply wouldnt
> work on some platforms, ive no idea, ive never tried it
It's also possible to do similar things without linker tricks.
E.g. define all functions as macros to add a ff_dl_wrap prefix,
then you can implement those wrappers in a different file and
from there do all the dlopen handling (making them function pointers
would probably be an option, too).
There are many options how to do things in detail from there on,
though most likely it would make sense to try to dlopen/dlsym all libraries
when registering the codecs (and not register those where dlopen or
one dlsym fails).
Adding a header that contains those defines should then be the
only change besides the dlopen logic itself that should be necessary.
There might even be some way to auto-generate some of the code.
If you rely on Bsymbolic linking (possible even without it), the
macros to rename the functions might not even be necessary.
The lazy linking even where supported has the risk that dlopen or
whatever you used worked but the symbol then isn't found in the end,
and then you get crashes... It's a least-impact approach, but it
seems risky.
More information about the ffmpeg-devel
mailing list