On 22 Aug 2016, at 08:26, Matthias Andree <matthias.and...@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 _______________________________________________ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
