[FFmpeg-devel] Shared libraries major version

Nicolas George george at nsup.org
Sat Nov 30 13:55:15 CET 2013


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

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.

Second solution: bump lavfi to a completely different numbering, such as
101. Still a lot of problems for applications that have

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

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 hope I have summarized the issue clearly enough and not made too many
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20131130/67cbfb9c/attachment.asc>

More information about the ffmpeg-devel mailing list