In my opinion, gcc-config needs select of runtime ld.so.conf paths feature. In current versions, paths are sorted (/etc/ld.so.conf.d/05gcc-x86_64-pc-linux-gnu.conf). I think this can potentially lead to problems due to ABI compatible for >=C++11 standard. If I merge the latest GCC version for work project compilation in my home directory, I do not have to change path for system. It should be as gcc-config default. The another example is a crossdev build. If I wanna use the latest GCC version for build ARM toolchain (with static link in my applications), I don't have to change the path in the system. Yes, I can repair paths by hands, but the new select feature will be a more competent solution.
There is another practical example. I can update GCC (not stable version) and have bugs at certain packages in system. I will need to downgrade GCC, but the "bad" GCC version is needed for compile my work projects and I wan't to unmerge it. So, it it would be good to change both GCC version (downgrade version) and libs order in 05gcc-x86_64-pc-linux-gnu.conf by gcc-config.
the sorting order of the ld.so.conf.d file is already what we want and should not be changed by the user: it's sorted by version (newest to oldest). users don't want to change this, and most who think they do don't understand the implications of screwing around with the file. this file only controls the runtime lookup paths. when you link with older gcc versions (such as using `g++-4.9.4 ...`), then gcc itself constructs a link path so that it refers to its own version-specific internal paths first, thus it links against the correct ABI version (even if it runs against a newer one). there's no need to modify the ld.so.conf files to accomplish that. the gcc-libs are designed to be ABI compatible which makes this possible. so what exactly is your request here ? your hypotheticals don't make sense to me.
(In reply to SpanKY from comment #2) > the gcc-libs are designed to be ABI compatible which makes this possible. OK. I understood you. In commit https://gitweb.gentoo.org/proj/gcc-config.git/commit/?id=5a1692cd6050b4c8d9e5d5cf45f24f83cd9cb405 we see: "We work off the assumption that every shared library gcc ships is ABI compatible". It's only assumption. GCC does not guarantee ABI stability C++11 and next standards for libstdc++. For example, I will install a new GCC version in second slot and select it by gcc-config. Potentially, I can get errors due to ABI incompatibility (as in versions 4.x!=4.y versions, https://bugs.gentoo.org/513386). I can downgrade GCC by gcc-config, but runtime lib will be from the newest GCC version (the top of 05gcc-x86_64-pc-linux-gnu.conf). Thus, errors will still be... There are two solutions: unmerge newest GCC or rebuild packages with new lib. In stable system, the second way is not good. But newest version of GCC can be used for compiling some projects in home directory, because it has new features. So, unmerge is not good to. And the third version (it's not correct), manually change in /etc/ld.so.conf.d/05gcc-x86_64-pc-linux-gnu.conf. In the current version of gcc-config, the downgrade of the version is poorly implemented. I think, that select libstdc++ version feature will be very beautiful solution. It will not be as default property, but only feature.
(In reply to Vyacheslav from comment #3) > GCC does not guarantee ABI stability C++11 and next standards > for libstdc++. Of course, GCC makes C++11 ABI stability guarantees beginning with version 5.1, but old versions are not deprecated in Portage. So, I think about potential conflicts (plus C++14/C++17). If this problem is not real, then I admit that I'm wrong.
(In reply to Vyacheslav from comment #3) there are a few cases where the ABI broke such as bug 513386. what you're proposing (the default ABI is based on default gcc-config selected profile) means everything breaks when people select an older version (see bug 297685). that is way worse than a few uncommon cases, and certainly not what the majority of Gentoo users expect or want. in general, Gentoo doesn't support upgrading to a newer library, building things against it, and then downgrading and expecting things to work. it's simply not feasible with any of the package managers we have now. you can force a specific linkage to use a specific runtime by using -Wl,-rpath,$(gcc-config -L). but you'll still have the problem where any libraries you use from the system which were built using newer gcc expect newer ABIs. there is pretty much no desire for this functionality in the system and is just asking for people to brick their systems. if you want to do something unusual, you can already do so: the gcc files were specifically named with a "05" prefix, so use a smaller prefix like "00" pointing to whatever old ABI you want (and then keep the pieces when things break).
Mike, thank you very much for detailed answer and proposed solutions.
