Summary: | x11-libs/vte-0.66.2 requires g++20, but does not depend on a matching gcc | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Thomas <tg42> |
Component: | Current packages | Assignee: | Gentoo Linux Gnome Desktop Team <gnome> |
Status: | UNCONFIRMED --- | ||
Severity: | normal | CC: | ionen, jstein |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
Thomas
2022-03-11 16:53:51 UTC
We can't really depend on a new enough GCC per se because it'll force GCC on systems without it like Clang. Best we can do is complain in pkg_pretend really. Note that 9.x is about to be EOL. (In reply to Sam James from comment #1) > We can't really depend on a new enough GCC per se because it'll force GCC on > systems without it like Clang. > > Best we can do is complain in pkg_pretend really. Note that 9.x is about to > be EOL. Thank you for your quick response. I thought portage would allow for dependencies on >gcc-x.y || >clang-p.q or similar. (But i am not sure if this is feasible, are there many alternative C compilers?) The workaround is obviously to upgrade gcc. (In reply to Thomas from comment #2) > Thank you for your quick response. I thought portage would allow for > dependencies on >gcc-x.y || >clang-p.q or similar. (But i am not sure if > this is feasible, are there many alternative C compilers?) The other issue is that it's not necessarily the compiler that's used e.g. you could have both gcc9 and gcc11 installed, and have gcc9 selected, and the dependency would think everything is fine given you have gcc11. People that don't depclean much tend to keep this state for a long time unintentionally too. (In reply to Ionen Wolkens from comment #3) > > The other issue is that it's not necessarily the compiler that's used > > e.g. you could have both gcc9 and gcc11 installed, and have gcc9 selected, > and the dependency would think everything is fine given you have gcc11. True. But the other (probably more common) situation, not having any working compiler installed at all, would be noticed by such a dependency. (In reply to Thomas from comment #4) > (In reply to Ionen Wolkens from comment #3) > > > > The other issue is that it's not necessarily the compiler that's used > > > > e.g. you could have both gcc9 and gcc11 installed, and have gcc9 selected, > > and the dependency would think everything is fine given you have gcc11. > > True. But the other (probably more common) situation, not having any > working compiler installed at all, would be noticed by such a dependency. Note that if we did || ( ) with clang + gcc, it may well end up just suggesting clang/pulling it in if newer GCC versions masked (which is likely the case for you). In general nobody should be masking new GCC versions. At most, requiring stable instead: sys-devel/gcc -~amd64 or similar. (In reply to Sam James from comment #5) > > Note that if we did || ( ) with clang + gcc, it may well end up just > suggesting clang/pulling it in if newer GCC versions masked (which is likely > the case for you). Good point. In my case it would probably be even happy with finding a matching clang -- which is not used here. > In general nobody should be masking new GCC versions. At most, requiring > stable instead: Newer versions of gcc have a tendency to be slower and more memory hungry without giving any benefit on the compiled binaries. BTW: there is even an unmasked gcc-8 in the reop. ;-) I am not sure if we want to add those checks at present time :/ Currently all gcc versions lower than 10 are hardmasked |