On 12.07.2014 20:51, Hendrik Leppkes wrote:
On Sat, Jul 12, 2014 at 8:42 PM, Andreas Cadhalpun
<andreas.cadhal...@googlemail.com> wrote:


OK, so either of us misunderstood what Hendrik wrote:
"[...] but that doesn't really change the fact that ff_* (and avpriv_*) are
not part of the public API/ABI and as such any changes or removals do not
require a SONAME bump."



The important point is that you should never use or care about any of
the ff* or avpriv* symbols, unless you are actually developing inside
the libraries.

I agree about never using these symbols externally, but that doesn't mean I don't have to care about them.

What happens to avpriv symbols is only a factor for in-between the av*
libraries, and of no concern to the users, since both are not part of
the official ABI/API.

That they are only used between the av* libraries means they are not part of the API, but still they *are* part of the ABI, simply because they appear in the symbol section of the .so file.

Anyhow, the original question has been resolved, and there sadly are a
bunch of hacks that require a few ff symbols to be exported for use in
between libraries, but its already grown a lot less over the last few
versions, and hopefully can be removed at some point.
And just because its exported doesn't make it officially part of the
ABI, though.

I'm not sure what you mean with 'officially' here. Every symbol exported by a shared library can be used by another program. Even if only other av* libraries use the avpriv_* symbols they can't just be removed, because that would break ABI compatibility between the old version of the library using such a symbol with the new version of the other library not exporting this symbol anymore.

The way Debian calculates the dependencies on shared libraries usually leads to dependencies >= some minimal version, which would allow to install the old version of one av* library together with the new version of the other (and with things like backports to stable, this is not that unlikely).

So if such a symbol gets removed, I have to take special care that it doesn't lead to problems.

For now that means I'm going to backport the commit removing ff_* from libswresample.v, so that I don't have to worry about it. (But I would have a problem now, if ffmpeg were already in Debian/sid).

Best regards,
Andreas
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Reply via email to