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? If these were, say: /usr/local/lib/gcc47/libgcc_s.so.2 /usr/local/lib/gcc48/libgcc_s.so.3 /usr/local/lib/gcc49/libgcc_s.so.4 /usr/local/lib/gcc5/libgcc_s.so.5 /usr/local/lib/gcc6/libgcc_s.so.6 /usr/local/lib/gcc7/libgcc_s.so.7 Or possibly the compatible ones folded into 2.0, 2.1, 2.2, 3.0 ... and our linker be taught that it can always grab a newer minor version, but not a different major version component, then that would also help because you then match the proper libgcc_s. Does libgcc_s version symbols when semantics change over releases? The counter-argument will be that it will be much harder to use indirectly linked libgcc_s (say, project A needs lib B and lib C, lib B depends on older libgcc_s than lib C) - but as I understood from past discussions (around libssl.so.X in that case) that causes crashes at run-time if the libraries aren't compatible, so this argument is invalid. > Steve's proposed scheme solves that quite nicely, in my opinion. The > problem is only in the details, as usual. There will be many configure > scripts and libtool-like utilities out there, that assume libgcc must be > linked using -lgcc_s, not -lgcc_s$VERSION. Which can be solved with proper -L options and does not incur renaming libraries.
signature.asc
Description: OpenPGP digital signature