[FFmpeg-devel] Round 2: Symbol versioning
Sun Dec 27 12:37:56 CET 2009
On Sun, Dec 27, 2009 at 12:20:28PM +0100, Reinhard Tartler wrote:
> Reimar D?ffinger <Reimar.Doeffinger at gmx.de> writes:
> > On Sun, Dec 27, 2009 at 10:35:14AM +0100, Reinhard Tartler wrote:
> >> These version scripts need to be adjusted on every SONAME bump.
> > Seems like a really bad idea to me, that will be forgotten.
> > I think it would be better to have them auto-generated or something.
> Version scripts are not fully automated, but need to be actually
> maintained, that's the point of symbol versioning.
> Of course we can generate these scripts with awk from subdir.mak, but
> we'd still need a list of symbol (patterns) that should be exported or
I was talking about the version number and only about that.
> >> libavformat and libavcodec are left rather liberal ATM because it is not
> >> clear at this point which symbols are supposed to be exported and which
> >> should rather be hidden. This file should be updated bit by bit by the
> >> respective file maintainers.
> > If it doesn't start with av_, ff_, avcodec_ or so it definitely should
> > not be exported, if it needs to be that should be fixed ASAP.
> In general I agree on this approach and in fact would welcome
> it. However, I assume that you are aware that this would instantly break
> building mplayer with a shared libavcodec and can take this statement as
> an offer to fix the resulting breakage in mplayer?
I have some doubts it will be possible. At least within a reasonable
However MPlayer issues are not really a good reason to do the wrong
thing in FFmpeg...
Lastly, it would be possible to export specific symbols that MPlayer
needs accompanied with a big // HACK and possibly only as a separate
patch or so.
> FYI, I'm attaching the list of symbols in libavcodec and libavformat
> with this patch applied. E.g. the functions url_* in libavformat seem to
> me 'public', but there might be more. So I think before implementing
> your change request, I'd love to see some more comments on this by other
Yes, that url_* stuff has always bothered me, but changing it needs a
major version bump I think.
And yes, I think it must be public, at least for now.
More information about the ffmpeg-devel