The static library discussion

[Clemens Lang]

Hi,

On Thu, Dec 22, 2011 at 01:33:38AM +0100, Marin Saric wrote:
> Example 1: ABI incompatibilities
> 
> x264 is a great example of where having it in a static form removes
> just the rebuilding problem that occurred now. x264 does not have a
> very stable ABI. It's source level API is consistent, but depending on
> what the version of x264 you download (new "snapshots" on something
> like a daily basis), your program is going to link against different
> symbols. In the newest version of x264 the ABI broke again.
> 
> Assume x264 is dynamic. Now assume a set of dynamic libraries H export
> symbols against an older ABI version of x264. Binaries depending on H
> and binaries dynamically linking against libraries depending on H all
> break once x264 is replaced with a new version. The old symbols are
> not found or, even worse, they are found but their semantics or
> interfaces have changed in a subtle way causing malfuction. Hence the
> "bump_dev_revs.sh" script, forcing a recompile of everything that
> depends on x264. If MacPorts were a binary-only distribution, we'd be
> in trouble.
> 
> This can be circumvented with "properly" versioning x264, but this is
> something outside of MacPorts control (IMHO too much involvement
> upstream).
> 
> One "bad apple" can wreak havoc on the whole system. Note that this is
> different than the symbol-collision problem fixed by two-level
> namespaces.

If the compatibility version and library verion fields are correctly set
in the resulting binary, this kind of problem can be detected and
automatically fixed by rev-upgrade.

-- 
Clemens Lang
GSoC Student