This is more or less something to stop bugs like bug #292174 A possible solution to this problem would be if say portage or the ebuild and/or eclass if the depended version of gcc is not the active version, then the emerge process should either while resolving deps drop that version of the package or early in the per ebuild process error out telling the user to change active GCC version, with the possibility to either FEATURES="-gccversioncheck" och an I_KNOW_WHAT_I_AM_DOING env var degrade it to ewarn (or keep the process in deptree with a warn). This is because glibc-2.11 is not the first package that depends on a specific version of GCC (old qemu-0.9 still lingering in memory) and I think this will not be the last, so maybe this should be a function either integrated into the package manager or into an eclass if possible so all ebuilds depending on >=sys-devel/gcc-X.Y has this automatic without further logic in the ebuild?
It's rather messy for the package manager to get involved in toolchain issues like this. It would be much cleaner for the ebuild which is picky about gcc to ensure by itself (or with the help of an eclass function) that it uses the correct gcc version. For example, this type of scenario is already common for things like python, where ebuilds are capable of building for multiple versions of python simultaeously, regardless of the default python interpreter setting.
I'll reassign this to pms-bugs since it involves interaction between package managers and ebuilds.
A much better solution would be for Gentoo to fix its GCC handling so that you can set per-shell compiler versions and not have to worry about libstdc++ breaking.
except for the part where gcc-config already supports per-shell gcc selection. and the part where this functionality has nothing to do with libstdc++.
Bug 330067 suggests otherwise...
that bug is not what was quoted in the original report, and it applies only to switching the system compiler. so it still isnt relevant to your comment since per-shell settings do not change the ldso lookup paths in any way.
btw, dont take my comments to indicate that i'm in favor of this change. i dont think the rare occurrences of user misconfigurations merit kludges in the PM.
(In reply to comment #7) > btw, dont take my comments to indicate that i'm in favor of this change. i > dont think the rare occurrences of user misconfigurations merit kludges in the > PM. > I am not out to help misconfigured users, I am out to stop confuse users. What I mean? Take an older stage3 file/installation (pre gcc-4.3, pre glibc-2.11) and run the following command: "emerge world -uD" This will sooner or later fail during merge of glibc with an message about missing cpuid.h header which for a casual user does not say a thing. They google it, and may find such ridiculous workarounds as in stated bug which may even break their system. Why does this fail? Because the pm merge >=GCC-4.3 and thinks the depends for >=glibc-2.11 are satisfied (which they actually are not until you with gcc-config activate >=gcc-3.4) and tries to merge it. Mind the users configuration was correct when he started emerge. So why not have the PM or an eclass tell the users that the depends are not really satisfied with a unified error message (i.e. not a custom message for every ebuild that may have this problem) instead of giving them strange build errors?
Because the right fix is for ebuilds to set the compiler that they need, not fail if the compiler hasn't been changed. Unfortunately, if ebuilds do that right now, then any C++ binaries they install will then not be runnable. Having said that, you can get the behaviour you're after using EAPI 4 pkg_pretend.
not really. ebuilds shouldnt be transparently picking random compilers different from what the user has selected. further, i dont know why you think C++ binaries would be broken -- they wouldnt be. actually read the bug report you referenced earlier. it has nothing to do with the binaries themselves. any pkg_* check on the compiler would be fundamentally wrong. why would a binary package care what version of the compiler is installed if it is a DEPEND only issue (which this glibc bug is) ? who is to say the system even has a compiler to test at install time ?
No progress since more than 10 years, therefore closing. Feel free to reopen with a concrete proposal.
