Problems with out libgcc_s.so in base

[Dimitry Andric]

On 22 Aug 2016, at 08:26, Matthias Andree <matthias.andree at gmx.de> wrote:
> 
> Am 18.08.2016 um 14:48 schrieb Dimitry Andric:
>> For example, on one of my systems, I now have these:
>> 
>> /usr/local/lib/gcc47/libgcc_s.so.1
>> /usr/local/lib/gcc48/libgcc_s.so.1
>> /usr/local/lib/gcc49/libgcc_s.so.1
>> /usr/local/lib/gcc5/libgcc_s.so.1
>> /usr/local/lib/gcc6/libgcc_s.so.1
>> /usr/local/lib/gcc7/libgcc_s.so.1
> 
> This in itself - to me - seems to be the actual problem, how do
> different versions of the library the same major version?

The gcc folks use symbol versioning, see:

https://gcc.gnu.org/onlinedocs/libstdc++/manual/abi.html

This works incrementally, so libgcc from gcc N is backwards compatible
with all previous libgcc's from gcc < N.  Not the other way around, of
course.

On Linux systems, there are no compatibility problems as we have seen
them, because you simply install the most recent libgcc into /lib, and
all applications will use that.  Older applications will find their
older ABI through symbol versioning.

However, even on a Linux system you could get into trouble if you would
compile and install a newer version of gcc than the system's default.

Applications linked with that newer version would possibly require a
newer libgcc ABI, and you would have the same problem that we have now.

-Dimitry