[FFmpeg-devel] Shared libraries major version

[Michael Niedermayer]

On Sat, Nov 30, 2013 at 02:15:06PM +0100, Stefano Sabatini wrote:
> On date Saturday 2013-11-30 13:55:15 +0100, Nicolas George encoded:
> > Hi.
> > 
> > There is a compatibility problem with the shared libraries major versions,
> > at least in the ELF world.
> [...]
> > Still, there are ways of mitigating the problem. Mostly, they amount to
> > bumping immediately lavfi's SONAME, and optionally providing a stub library
> > for compatibility.
> > 
> > The obvious way is to bump lavfi to 4, of course. But in that case, we can
> > kiss compatibility with the fork goodbye when they bump.
> > 
> > Second solution: bump lavfi to a completely different numbering, such as
> > 101. Still a lot of problems for applications that have
> > LIBAVFILTER_VERSION_MAJOR ifdefry.
> > 
> > Third solution: since the problem is only with ELF shared libraries, bump
> > only the SONAME of the ELF shared library: libavfilter.so.3-55 for example.
> > 
> > (It could be taken to the next level: include all the dependencies versions
> > in all the SONAMEs; that would mean something like
> > libavfilter.so.3-55-55-0-0-52-52. That is rather ugly, and probably not
> > necessary.)
> > 
> > Fourth solution: kill the issue completely by merging all libraries
> > together. I realize some people here will consider it a troll, and I
> > apologize for that, but I personally think this would be the best move, even
> > without the SONAME issue.
> > 
> > I hope I have summarized the issue clearly enough and not made too many
> > mistakes.
> 
> Thanks for the detailed report. Since the problem was generated in the
> fork, maybe they are aware of the problem or we can notice them about
> it (don't know if someone is still reading this mailing list).
> 
> Clean solution is to bump lavfi major version as soon as possible, and
> keep broken what is broken. I don't like very much more complex
> versioning schemes.
> 

> About the big library merge, what are the technical advantages of that
> solution?

its a new thing that people dont know yet what issues it would cause



> Would it be possible to generate a libffmpeg.so library *as
> alternative* to the current split library set (enabled at
> configure-time)?

probably


[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

It is what and why we do it that matters, not just one of them.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20131130/19c5d9f3/attachment.asc>