[FFmpeg-devel] Upgrade Trouble

Michael Niedermayer michaelni
Sun Dec 6 21:00:43 CET 2009

On Sat, Dec 05, 2009 at 01:41:59PM +0100, Reinhard Tartler wrote:
> Michael Niedermayer <michaelni at gmx.at> writes:
> >> Indeed. The approach to statically prefix the SONAME to each symbol is
> >> trivial to implement, but leads to the situation that moving symbols
> >> from lavf to lavc effectively results in an ABI break that would require
> >> an SONAME bump.  This might be an acceptable compromise, but can only be
> >> avoided by using a more sophisticated approach for symbol versioning.
> >
> > For moving symbols between lavf->lavc we would need to keep the symbol with
> > the old version in lavf until the next bump but that would have to be under
> > some kind of #if ELF_SO_VERSIONING otherwise we could end up with 2 symbols
> > of the same name that might have some sideeffects
> Yes, that would indeed by an option if we go the "each symbol gets the
> 'full SONAME' as version tag" route.
> Do you want me to implement this?

What i think you will have to do is the following (this is a suggestion and
we should of course make sure this works and i missed nothing before doing

0. The version of libavutil should be the SONAME

1. you need a libavutil49 with versioning in debian, this can
   just be introduced without anything else being changed, it should not
   break existing binaries

2. you need to rebuild all libraries that depend on libavutil, you do NOT need
   to rebuild applications that depend on libavutil, this rebuild is needed
   so they contain dependancies with the new versioned libavutil49.
   Applications are already guranteed to link to the correct version by the
   ELF search order.

3. you need a libavutil50 with versioning in debian.
   This libavutil50 needs a Conflicts tag with libavutil49 prior to the
   introduction of versioning and ALL libraries that where build with
   libavutil49 of versions prior to the introduction of versioning.

if you want to add versioning to lavc/lavf too then they need the same
procedure as above.

alternatively you could also fix the linker so its search order is from the
object where a symbol is used instead of the application. Or you could
skip some of the points above and hope ...

Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

It is not what we do, but why we do it that matters.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20091206/6c7f8a47/attachment.pgp>

More information about the ffmpeg-devel mailing list