See bug 913628 for the discussion wrt rationale in general. I wonder if it might be worth carving out another special-case (like libc) for the C++ standard library provider. This becomes more of a problem on, say, app-alternatives/tar[libarchive,-gnu] systems where a libarchive->icu dependency exists (so C++ enters the picture earlier than otherwise). If we were to do this, we'd need to introduce a virtual/cxx (or virtual/libcxx, although that might confuse people as it might sound like it's referring to LLVM's sys-libs/libcxx which is just one possible provider) and then be a bit smarter about analysis, by checking if libstdc++ or libcxx is referenced in NEEDED before injecting a dependency. I think it's less clear cut about how to do this rather than the libc one, but worth positing...
This matters for the general case of upgrading gcc (or libcxx) before a package which needs it but the "bricking" issue is limited to the app-alternatives kind of situation I mention above as otherwise these tend to get upgraded at the right time without any issues occurring.
If it were libarchive itself, we could do -static-libstdc++ and such, but it's the ICU part which is a problem.
i'm somewhat skeptical of further special-casing.. perhaps we should just inject library deps into the @system set?
This unfortunately shows up on the binhost as we switched to using GCC 14 there very quickly after it became stable. If a consumer doesn't yet have GCC 14, when they update, they may get e.g. an ICU binary linked against GCC 14's libstdc++ and then gpg (gpg->sqlite->icu) is broken and can't be used to verify binpkgs.
(In reply to Sam James from comment #4) > [...] > If a consumer doesn't yet have GCC 14, when they update, they may get e.g. > an ICU binary linked against GCC 14's libstdc++ and then gpg > (gpg->sqlite->icu) is broken and can't be used to verify binpkgs. (See bug 930730 for not being able to disable gpg temporarily.)
Zac, what do you reckon we should do here? If we add libstdc++ (via gcc) to the list, we will probably need a way to turn it off, and also certainly to actually check if libstdc++ is used rather than just if NEEDED exists as we do for glibc. We're also then kind of approaching that "list of critical packages" you mentioned in https://bugs.gentoo.org/283422#c2. At least for libc+os-headers, while we have the ASAP logic, the implicit RDEPEND thing is consistent with that rather than adding another package to the mix. On the other hand, implementing bug 753500 is harder and will need more work.
(In reply to Sam James from comment #4) > This unfortunately shows up on the binhost as we switched to using GCC 14 > there very quickly after it became stable. > > If a consumer doesn't yet have GCC 14, when they update, they may get e.g. > an ICU binary linked against GCC 14's libstdc++ and then gpg > (gpg->sqlite->icu) is broken and can't be used to verify binpkgs. Can we use a slot-operator dep on sys-devel/gcc:= in the icu package here? That way it should handle it nicely, yes?
bug 753500 is a generic solution to this problem, but it *specifically* doesn't work for libstdc++ because the symbols look like GCC 13.1 --> GLIBCXX_3.4.31 GCC 13.2 --> GLIBCXX_3.4.32 GCC 14.1 --> GLIBCXX_3.4.33 There's no way to get back from a checked symbol to the version you depend on. However, if you nm -D every ELF file in the image and check if they depend on GLIBCXX_ at all, then you could inject a >= on whatever is currently installed, just like we do for glibc already. (In reply to Zac Medico from comment #7) > (In reply to Sam James from comment #4) > > This unfortunately shows up on the binhost as we switched to using GCC 14 > > there very quickly after it became stable. > > > > If a consumer doesn't yet have GCC 14, when they update, they may get e.g. > > an ICU binary linked against GCC 14's libstdc++ and then gpg > > (gpg->sqlite->icu) is broken and can't be used to verify binpkgs. > > Can we use a slot-operator dep on sys-devel/gcc:= in the icu package here? > That way it should handle it nicely, yes? What, and force people to retain GCC 13, which icu was built with, even when installing GCC 14? We need >=, we can't do binding slots. icu could explicitly ask for >= gcc-as-used, if bug 938948 was solved. But only if you could tell through pure ebuild metadata that make.conf CXXFLAGS doesn't have -stdlib=libc++, which is simply not how ebuild metadata works unfortunately (would be neat if it did, obsolete lots of pkg_pretend use cases).
