[FFmpeg-devel] Upgrade Trouble

[Reinhard Tartler]

Sorry for my late answer, I wanted to do some further experiments with
symbol versioning before posting this email and got caught up with work
and family stuff :-(

Michael Niedermayer <michaelni at gmx.at> writes:

> 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
> anything)
>
> 0. The version of libavutil should be the SONAME

Just to be clear, we want to version symbols, not libraries. The version
of libavutil is the SONAME, currently the string "libavutil.so.50" in
current trunk. I therefore understand you want to assign the version
string "LIBAVUTIL_SO_50" (or similar) to each symbol publicly exported
by libavutil.

Then we still have the option to either use a simple, single wildcard
rule (library wide), or explicitly list all symbols that are meant to be
exported. The latter would allow to avoid exporting private symbols to
3rd party applications.

> 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

I'd love to see this implemented in the 0.5 release branch. This is not
a requisite, but would save me yet another distro patch against the
upstream sources, and feels just natural to me.

> 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.

While this is certainly not wrong, rebuilding *all* DSOs, including
applications is the only sane thing to do here. Let me explain why:

 - You are correct that introducing symbol versions in an library with
   previously unversioned symbols does not break existing application
   binaries.

 - However, rebuilding them will cause the application to "pick-up" the
   versioned symbol references. This can and will happen if applications
   need to be updated for some reason (think security updates or
   packaging fixes, etc.)

 - Therefore, after implementing symbol versioning in the distro
   FFmpeg0.5 packages, I'm going to request rebuilds of all libraries
   and application packages. This is a safe thing to do as we require
   all sources to be buildable in the distro.

 - With the SONAME based version, this would imply "LIBAVCODEC_SO_52",
   "LIBAVFORMAT_SO_52" and similar version strings for the other
   libraries.

 - As a side effect, this rebuilding of all applications packages will
   instantly make all debian binaries linking against ffmpeg libraries
   instantly fail to start when used against 3rd party library packages
   that do not use symbol versioning (yes, debian-multimedia.org, I'm
   looking angrily at you!)

> 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.

This is correct. I'm going to implement this with a versioned conflicts
because this  also implies the second part.

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

For practical reasons, I'll strongly suggest to start symbol versioning
on *all* libraries at the same time.  This includes libswscale,
libpostproc, libavdevice and libavfilter.

> 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 ...

Indeed, however I currently think the symbol versioning route is the
most promising way from here.

-- 
Gruesse/greetings,
Reinhard Tartler, KeyID 945348A4