[FFmpeg-devel] Symbol versioning failure on Android

Martin Storsjö martin
Tue Dec 7 15:39:11 CET 2010


On Tue, 7 Dec 2010, Michael Niedermayer wrote:

> On Tue, Dec 07, 2010 at 08:30:43AM +0200, Martin Storsj? wrote:
> > On Tue, 7 Dec 2010, Michael Niedermayer wrote:
> > 
> > > On Tue, Dec 07, 2010 at 12:33:13AM +0200, Martin Storsj? wrote:
> > > > Hi,
> > > > 
> > > > If building shared libraries on Android, there seems to be a problem with 
> > > > symbol versioning. The fallback symbols in the previous library, defined 
> > > > e.g. in libavcodec/opt.c should call the new ones in libavutil/opt.c. In 
> > > > practice, they just call themselves, looping infinitely.
> > > > 
> > > > Does anyone have better insight into the symbol versioning stuff, that 
> > > > could point out what could be going wrong?
> > > 
> > > I dont know the fine details of what is going wrong on android but
> > > IMO the fundamental problem is that the bugs in the gnu linker prevent a clean
> > > implementation of moving symbols between libs. And all these hacks with wrapers
> > > calling themself and "magic" asm symbol versioning statements is something
> > > that i must admit i was surprised works at all and i have no interrest in
> > > finding even more insane workarounds of the gnu linker bugs that also work on
> > > android.
> > > 
> > > It would be interresting to know if android could handle a sanely moved symbol,
> > > that is one that during compile/link time was in one lib and during runtime
> > > then was in another lib (with matching version of course)
> > 
> > I think the problem in our case is that the symbols have different version 
> > depending on which library they reside in, there's no guarantee that 
> > symbol at LIBAVCODEC42 is compatible with symbol at LIBAVUTIL52. The wrappers 
> > provide the previous version, for compatibility.
> 
> its a matter of 1 line in the version script to move a symbol at LIBAVCODEC42
> to libavutil and keep it symbol at LIBAVCODEC42 (which then can be changed to
> LIBAVUTIL53 in the next ABI bump)
> gnus runtime linker cant handle this though (see the archives for details and
> patches that fix the linker)

Ok then.

Anyone else more familiar with the runtime linker that can guess what's 
going wrong, or are in favor of or oppose adding a configure flag for 
disabling the symbol versioning?

// Martin



More information about the ffmpeg-devel mailing list