[FFmpeg-devel] Shared libraries major version

[Michael Niedermayer]

On Sat, Nov 30, 2013 at 01:55:15PM +0100, Nicolas George 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.

it should work when all components involved use symbol versioning
(that means all, a single libav* or app involved not using symbol
 versioning can cause the linker to match symbols up in illogical ways,
 at least it did a few years ago)

That of course doesnt mean it does work, just that symbols should get
matched up correctly when old and new libs as well as the app uses
symbol versioning

I think the actual observed problem occurs due to AVFrames being
used in old lavfi at a small number of places and AVFrame being
allocated by libavcodec
at the 1.2 time while later in libavutil, so depending on from where
the structs come they have different size, and new functions and
accessors will not neccessarily work with the old structs, similarly
old accessors from lavc will have problems with lavu based structs


[...]
> 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.)

yes, this luckily limits the actual problem

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

What does censorship reveal? It reveals fear. -- Julian Assange
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20131130/419b127b/attachment.asc>