[FFmpeg-devel] Shared libraries major version

[Timothy Gu]

On Nov 30, 2013 4:55 AM, "Nicolas George" <george at nsup.org> wrote:
>
> Hi.
>
> There is a compatibility problem with the shared libraries major versions,
> at least in the ELF world.
>
> Here is the story:
>
> Since 2012-05-16, libavfi is at version 3, and since 2012-10-22, lavu is
at
> version 52.
>
> On 2013-03-12 (the actual commit is from 2013-02-17, but it was only
merged
> a month later), lavc and lavf were bumped from 54 to 55. lavfi was not
> updated.
>
> But lavfi depends on lavc and lavf (that is optional, but enabled by
> default). For the rest of the mail I will speak of lavc only.
>
> The result is that libavfilter.so.3 built with a source before lavc's bump
> needs (as in NEEDED in the ELF headers) libavcodec.so.54 while
> libavfilter.so.3 built with a source after needs libavcodec.so.55.
>
> The same applies to any application using lavc; if that application also
> uses lavfi, it will need libavfilter.so.3.
>
> As a consequence, if you have an application built before 2013-02-17 and
try
> to use it with a more recent lavfi, it will load both libavcodec.so.54 due
> to its own needs and libavcodec.so.55 through lavfi.
>
> Theoretically, it could work, because lavfi does not shows the lavc data
> structures it uses to the application: the application would call
functions
> from lavc 54 and lavfi would call functions from lavc 55. But that is not
> the ELF linking model, it does not work that way. Instead, functions are
> called from one of the version in an unspecified way.
>
> The short of it is that libavfilter.so.3 > 2013-02-17, despite having the
> same SONAME and exactly the same ABI, is incompatible with
libavfilter.so.3
> < 2013-02-17.
>
> The basic rule is: whenever a shared libraries breaks ABI and bumps its
> SONAME, all shared libraries depending on it should bump their SONAME too
> (or be declared incompatible some other way).
>
> Distributions have a long history of having to deal with that problem,
from
> libc's version bumps and threaded/non-threaded variants to bumps from
> ubiquitous third party libraries such as OpenSSL or libjpeg. Some have
> decided to handle the whole SONAME issue completely themselves.
>
> FFmpeg 1.2 was branched around 2013-03-08, just before the lavc bump was
> merged. FFmpeg 2.0 and 2.1 were branched after.
>
> The short of it is that if you have a system with FFmpeg 1.2 and a lot of
> applications linked to it, and you try to upgrade FFmpeg to 2.1, all your
> applications will break.
>
> (Well, only applications linked with lavfi; they are still not many.)
>
> Note that the fork has exactly the same problem: their version 9 branch
> dates from 2013-01-05, before the bump, and their git head is
incompatible.
> They have made no releases since then.
>
> There is no good solution to this problem. Unless I am mistaken, the 2.0
and
> 2.1 branches are unsalvageable, and there is no way of maintaining
> compatibility both with the fork and the older versions.
>
> Still, there are ways of mitigating the problem. Mostly, they amount to
> bumping immediately lavfi's SONAME, and optionally providing a stub
library
> for compatibility.
>

> The obvious way is to bump lavfi to 4, of course. But in that case, we can
> kiss compatibility with the fork goodbye when they bump.

Can someone familiar with fork (Daemon404?) ask fork's opinion on this?

>
> Second solution: bump lavfi to a completely different numbering, such as
> 101. Still a lot of problems for applications that have
> LIBAVFILTER_VERSION_MAJOR ifdefry.
>
> Third solution: since the problem is only with ELF shared libraries, bump
> only the SONAME of the ELF shared library: libavfilter.so.3-55 for
example.
>
> (It could be taken to the next level: include all the dependencies
versions
> in all the SONAMEs; that would mean something like
> libavfilter.so.3-55-55-0-0-52-52. That is rather ugly, and probably not
> necessary.)
>

> Fourth solution: kill the issue completely by merging all libraries
> together. I realize some people here will consider it a troll, and I
> apologize for that, but I personally think this would be the best move,
even
> without the SONAME issue.

I like this :)
But I think if this is the way to go, libraries that don't get as frequent
major bumps (e.g. lsws, lswr, lavr, lpp) should then be kept where they are
or be moved to a separate library, to eliminate unnecessary major bumps.

>
> I hope I have summarized the issue clearly enough and not made too many
> mistakes.