Boost logo

Boost :

From: Edward Diener (eldiener_at_[hidden])
Date: 2020-12-02 14:55:58

On 12/2/2020 9:42 AM, Andrey Semashev via Boost wrote:
> On 12/2/20 5:08 PM, Edward Diener via Boost wrote:
>> On 12/2/2020 5:12 AM, Andrey Semashev via Boost wrote:
>>> On 12/2/20 1:21 AM, Edward Diener via Boost wrote:
>>>> I believe the great majority of Boost libraries attempt to maintain
>>>> ABI compatibility between releases.
>>> My impression is the opposite. Boost has never declared backward ABI
>>> or API compatibility. There's a reason why binary distributions of
>>> Boost append a version tag that matches Boost version to packages and
>>> binaries.
>> Whether Boost declares it or not I do not think Boost libraries change
>> the API or ABI very often between releases and, if they do, they will
>> notify the end-user about it.
> No, not really. Internal changes are often not reflected in the release
> notes at all, while they may affect ABI.

If the binary interface between the end-user and a library remains the
same I do not think changes to some internal structure or internal
functionality matters. Can you give an example where it does ?

> You may have an impression of stability because many Boost libraries
> don't change that much (e.g. due to lack of maintenance). This is not a
> result of a maintenance decision, but a product of the lack of
> development. Hence this is not a guarantee or promise or whatever that
> ABI/API is stable.
>> So are you telling me that if I have gcc-10.2 I should be able to use
>> the gcc-5.1 libstdc without any ABI problems ?
> No, because a program compiled with gcc 10 may use symbols of the
> standard library that were not available in gcc 5. But you could do the
> other way around - have your program compiled by gcc 5 and run it with
> libstdc++ from gcc 10. People do this rather often, when they install
> pre-compiled binaries from external sources (i.e. not from the distro
> repositories).
> There are a few ABI changes that were made in gcc (the compiler, not
> libstdc++), but there are options to highlight code affected by them or
> switch to the older behavior. I did not research whether libstdc++ is
> affected by those, but I would assume either not affected or the
> necessary workarounds are in place.

Boost list run by bdawes at, gregod at, cpdaniel at, john at