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.
