[FFmpeg-devel] Round 2: Symbol versioning

[Reimar Döffinger]

On Mon, Dec 28, 2009 at 12:02:22PM +0000, M?ns Rullg?rd wrote:
> Reinhard Tartler <siretart at tauware.de> writes:
> 
> > Michael Niedermayer <michaelni at gmx.at> writes:
> >
> >> On Sun, Dec 27, 2009 at 10:35:14AM +0100, Reinhard Tartler wrote:
> >> [...]
> >>> diff --git a/libavcodec/libavcodec.v b/libavcodec/libavcodec.v
> >>> new file mode 100644
> >>> index 0000000..2be912f
> >>> --- /dev/null
> >>> +++ b/libavcodec/libavcodec.v
> >>> @@ -0,0 +1,3 @@
> >>> +LIBAVCODEC_52 {
> >>> +	global: *;
> >>> +};
> >>
> >> this is fine but note that to introduce symbol versioning you can only
> >> do above the first time. Subsequent sonames need a dummy entry like
> >> X{};
> >>
> >> This is because ld.so slightly favors the first version for binding
> >> unversioned references
> >> (in unchanged gnu ld.so the effect is limited to libs that define
> >>  multiple symbols with the same name)
> >> in my patched version though this is essential so unversioned references
> >> are bound to the correct versioned definition if no unversioned definition
> >> exists across libraries.
> >> (its a ugly hack but ld.so already uses this check and i didnt want to
> >>  introduce another different approuch)
> >> also the empty X version does no harm ...
> >
> > Okay, this means that libavcodec.v cannot really be generated
> > (cf. discussion with Raimar in this thread) but must be maintained
> > manually.
> 
> It can probably be generated from some kind of template to ensure the
> version numbers stay in sync.

Yes, auto-generating the version number is still the only thing I am
talking about and is completely orthogonal to everything else.
And I still think it completely unacceptable to have to change the major
version number in more than one place, this is almost guaranteed to
cause issues.