Re: The new Boost 17.0.0

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.