[FFmpeg-devel] Upgrade Trouble
Tue Dec 8 04:16:16 CET 2009
On Mon, Dec 07, 2009 at 10:08:36PM +0100, Reinhard Tartler wrote:
> 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.
"LIBAVUTIL_50" should be fine
> 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.
I think exporting only public symbols would be very nice. I would suggest
though to first commit a simple single wildcard rule and in a seperate
svn revission replace that by av*,ff*,"historic cases". (that is 2
wildcard rules and a list of exceptions)
> > 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.
Iam fine with applying a versioning patch to 0.5, you have to convince
diego though too as he is the one in charge for the 0.5 branch.
> > 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
> - 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
> - 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!)
indeed, this is funny, ld.so dies with an assertion failure.
another bug in the linker IMO
It will also break your applications though if they can end up being linked
with unversioned libs
Are you sure its not worthwhile to fix the linker? This dependancy & conflict
dance has to be done each time a project wants to add versioning.
The linker should do the following (and it does not)
1. Prefer a symbol with matching version over an unversioned symbol.
Not just pick the first that does not have a mismatching version.
2. do a breadth first search from the object where a symbol is referenced
Not a breadth first search from the application.
3. Not fail assertions.
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
Size: 189 bytes
Desc: Digital signature
More information about the ffmpeg-devel