Ahh, I understand now what was meant with the statement. Often it is
easier to understand things using an example.
Thanks a lot for your time.
On 2020-07-24 22:11, Jonathan Wakely wrote:
On Fri, 24 Jul 2020 at 16:12, Nyquist via Gcc-help <gcc-help@xxxxxxxxxxx> wrote:
Hi,
wondering if someone can give me more information about the following
sentence from the GCC ABI Policy and Guidelines page: "The reverse
(backwards compatibility) is not true. It is not possible to take
program binaries linked with the latest version of a library binary in a
release series (with additional symbols added), substitute in the
initial release of the library binary, and remain link compatible." For
example, does the statement apply to the following scenarios?
Lets assume I have an shared library L and an executable E and I am
linking dynamically with the libstdc++. Everything is compiled with GCC
9.1. Am I allowed (regarding ABI compatibility) to:
- change internal code (no API/interface) in E, compile it with GCC10.1
and release? (Executable E compiled with GCC10.1, Library L compiled
with GCC9.1, libstdc++ from 9.1)
No. The executable E was linked with libstdc++.so.6.0.28 from GCC 10.1
and so you need to use libstdc++.so.6.0.28 (or newer) when you run the
executable.
- change internal code (no API/interface) in L, compile it with GCC10.1
and release? (Executable E compiled with GCC9.1, Library L compiled with
GCC10.1, libstdc++ from 9.1)
No. The library L was linked with libstdc++.so.6.0.28 from GCC 10.1
and so you need to use libstdc++.so.6.0.28 (or newer) when you run the
executable.
Also lets assume that the new code uses only features which already
exist in libstdc++9.1. Would the scenarios above work if I change the
libstdc++ to the one shipped with the GCC10.1 compiler?
Yes, that is the "or newer" condition.
