When building =app-portage/eix-0.25.5 without a C++ compiler installed, the build fails at the configure step with: checking whether the C++ compiler works... no configure: error: in `/var/tmp/portage/app-portage/eix-0.25.5/work/eix-0.25.5': configure: error: C++ compiler cannot create executables The package should express a bdep on gcc[cxx], to ensure the presence of a C++ compiler at build time.
In the case of eix, we would need this only if clang is not used !clang? ( sys-devel/gcc[cxx] ) However, the dependency sys-devel/gcc[cxx] is not correct, either: For instance, when I wanted to install new gcc:4.8[-fortran] for testing and a package in world bdepends on sys-devel/gcc[fortran], portage is not able to proceed (if --with-bdeps is active). This is just false, since installing a new gcc does not mean that the system's gcc looses fortran capability. So the correct dependency should be something like !clang? ( || ( sys-devel/gcc:4.8[cxx] sys-devel/gcc:4.7[cxx] ...) ) covering all gcc slots and needing to be updated whenever a new gcc slot appears. This is somehow stupid and actually not correct either, since it does not guarantee that the system's gcc was compiled with USE=cxx. I cannot see how one could express a correct dependency with current possibilities. Perhaps a general solution for such type of dependencies should be found in a new EAPI and we should wait until a correct solution is found?
As Martin said; there is no easy route for this. The closest we can do is provide a message via pkg_pretend that will tell users that eix is likely to fail at configure time, so they know before doing a big emerge that their current environment won't support compilation and failure at configure time is expected. I'm not sure this would be worth it; realistically, this bug is akin to an improperly setup environment (gcc-config not run to select a compiler, etc), and we don't try to provide pre-emerge warnings on those situations. Thoughts?
My understanding of --with-bdeps is that Portage is supposed to ensure that the dependency is satisfied at build time. This does not suggest to me that Portage *should* fail out in the circumstance Martin describes; I would desire Portage to take steps to build the package at the time the bdep requirement is needed, but not be concerned before or after. Really, I expect Martin's described scenario to be resolved by a resolution to bug 175808.
(In reply to comment #3) > My understanding of --with-bdeps is that Portage is supposed to ensure that > the dependency is satisfied at build time. That is true for libraries, but toolchain dependencies (especially gcc) are not possible to resolve in this manner and --with-bdeps does not handle these cases. Portage's dependency resolution can only go so far as to tell you that there is an atom installed which satisfies (R)DEPENDs; it does not and cannot check if the tools you have installed are operational or are selected for use. There is a similar issue when, for instance, trying to determine a fortran compiler (there are many available in the tree but no way to guarantee that, even if one is emerged, you have something that can make you a binary). To reiterate by example: say we add gcc[cxx] as a dependency. Portage would then (re)install gcc-4.6.3 with USE=+cxx. However, a user may have gcc-4.5.4 selected via gcc-config and since it WASNT installed with USE=+cxx , eix will still fail at configure time.
Also, --with-bdeps is intended to be entirely optional, so if you need it in order to avoid a build failure then something is wrong. The point of --with-bdeps is to pull in updates of build-time dependencies for packages that are already built/installed, which is useful for ensuring that all installed packages are at the latest available version.
see bug 466056
