From: Daniel James (daniel_james_at_[hidden])
Date: 2008-04-24 05:38:51
2008/4/24 Jens Seidel <jensseidel_at_[hidden]>:
> > http://svn.boost.org/trac/boost/changeset/44440
> Is this really a problem? It affects only a private header file in
> detail/ no user should use. The changelog isn't very verbose but
> "Disable sync use for arm and hppa." could be justified if the previous
> code was just buggy or unsupported (no need to keep the some compilation
> bug for a new version as in the old one).
Well, I don't know the story behind that change, but if the 1.35
version compiles then it means that different parts of the program
will use different implementations of the counter object, which I
assume are incompatible. Also, since the bug is in the support for
multi-threading on a particular platform it could be the case that a
program is using the buggy version and not aware of it.
> > We do so much in headers that this would require a lot of discipline
> > and prevent a lot of fixes. It'd be nice to be able to test for ABI
> > compatibility, perhaps by running the tests with one version, and the
> > libraries with another. Would that be effective? We'd also need more
> > frequent releases so that those fixes could be pushed out sooner but
> > we need that anyway.
> Debian (www.debian.org) contains the packages
> icheck: C interface ABI/API checker
> abicheck: binary compatibility checking tool
> Comparing the symbols in the libraries is probably more effective than
> applying a few tests.
Yes, you're probably right. Although I think it'd still be worth
running some sort of tests in addition.
I might have made a terminology mistake and was writing about more
than just ABI compatibility. A simple example: if I made a change to
Boost.Hash that caused it to return different hash values, then
different parts of the program would be generating different hash
values which would cause problems if they accessed the same hash
table. But I don't think it would break ABI compatibility. And we
don't have any tests that would detect something like that. That one
is pretty obvious, but I worry that there might be more subtle
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk