[Ffmpeg-devel] [RFC] dlopen vs linking for external libraries

Uoti Urpala uoti.urpala
Mon Feb 12 06:57:36 CET 2007


On Mon, 2007-02-12 at 03:13 +0100, Michael Niedermayer wrote:
> well i do have many gb but i still feel fairly unhappy if i have to install
> 100mb of things i dont need and which may even make my system less secure

I wouldn't consider 100 MiB for the whole distro bad. In Debian you
could probably save more in easier ways such as moving all documentation
away from binary packages.

> in ffmpegs case, lets assume any of the external
> libs is exploitable, simply having it linked and trying to play a file which
> uses that lib could lead to your system to be exploited ...

And how would people know not to install the necessary libs to play it?

> > In addition to the extra complexity in the program code dlopen() makes
> > the program more brittle and creates other problems for distros. It
> > makes it impossible to verify correct dependencies from the binary
> > directly (which is usually done in Debian) and makes it harder for other
> > packages to depend on the program (if I need functionality X how do I
> > express that when program Y might or might not support that depending on
> > what else is installed? Depend on Y+exactly what?).
> 
> for example
> myprog 2.3.4
> depends: ffmpeg-faad >= 1.2.3
> 
> ffmpeg-faad 1.2.3 (virtual package)
> depends: ffmpeg=1.2.3, faad >= 3.4

It cannot be a virtual package if it has dependencies.

> or a million variations of that ...

Creating lots of extra packages like that would cause problems (bigger
package lists, more things for people to browse through etc).

> > What I do claim is:
> > 1. Moving possible package dependencies to dlopen() when they're not
> > necessary for every user would be a net loss for binary distributions,
> > with some (rare) exceptions for huge libraries.
> > 
> > I gave some reasons above; if you want more detailed explanations then
> > you should probably contact someone directly working on the distros.
> 
> well you argue against dlopen() support iam arguing in favor of it, you
> will have to find arguments against it yourself if you care ...
> 
> "iam against foobar, for details please ask <random large group of people>"

I did mention problems caused by using dlopen() instead of dependencies.
You haven't given any more details about the benefits either beyond just
mentioning "disk space savings" (no analysis of how big a practical
benefit that would give to how many people). I'm not interested enough
to write a detailed analysis of all effects of using dlopen() and
whether/how various ways to avoid negative effects would fail (if that's
what you would want).

> > 2. Space savings for FFmpeg which is typically used with large files
> > matter less than for programs which are typically used with only small
> > external data.
> > 
> > I think this should be common sense...
> 
> maybe your common sense but not mine, i still care about a few mb even if i
> have a few gb free

I consider that irrational if by "caring" you mean willingness to do any
nonnegligible extra work to save the few MiB.

>  and as said above there are also security issues

IMO those are not real security issues. For most people the right choice
would be installing all the features rather than trying to guess exactly
which ones they would need. When would you decide "I wanted to play
this, but now that I see it uses format X I changed my mind"? If it's
known that some formats are particularly insecure then it's probably
better to add an "--allow-insecure" switch to the executables or
something like that.

> furthermore for the embeded case the storeage space for
> excutables might differ from that for media files (how many dvds bought in the
> shop contain a ffplay execuatble? or how many satelite trasmissions of movies
> contain libavcodec?)

For the embedded case I'd expect people to want custom executables. If
you consider modularity of binaries so important how about making each
codec in FFmpeg a separate .so?

> > If the dlopen() features do not interfere with other code then I have
> > nothing against keeping the option to use them in FFmpeg.
> 
> great so we agree

I disagree with your earlier "keep dlopen and drop linking if you want
to drop something". Plus your earlier complaining about distro
dependencies - I think the distros mostly do that right.





More information about the ffmpeg-devel mailing list