"Only gcc version(s) 4.7 4.8 4.9 5.3 5.4 6.3 6.4 7.2 7.3 are supported" excerpt from: >>> Preparing source in /var/tmp/portage/sci-libs/tensorflow-2.1.0_rc0/work/tensorflow-2.1.0-rc0 ... * Applying tensorflow-1.15.0_rc0-0001-WORKSPACE-add-rules-docker-http_archive-bazel-toolch.patch ... [ ok ] * Applying tensorflow-2.1.0-external_libs.patch ... [ ok ] * Will copy sources from /var/tmp/portage/sci-libs/tensorflow-2.1.0_rc0/work/tensorflow-2.1.0-rc0 * python3_6: copying to /var/tmp/portage/sci-libs/tensorflow-2.1.0_rc0/work/tensorflow-2.1.0-rc0-python3_6 >>> Source prepared. >>> Configuring source in /var/tmp/portage/sci-libs/tensorflow-2.1.0_rc0/work/tensorflow-2.1.0-rc0 ... * python3_6: running run_in_build_dir do_configure * Only gcc version(s) 4.7 4.8 4.9 5.3 5.4 6.3 6.4 7.2 7.3 are supported, * of which none is installed * ERROR: sci-libs/tensorflow-2.1.0_rc0::gentoo failed (configure phase): * Only gcc version(s) 4.7 4.8 4.9 5.3 5.4 6.3 6.4 7.2 7.3 are supported
This is the best we can do currently. The slotting of the C/C++ toolchains on Gentoo doesn't work as well as you might expect. If your build system requires python2, for example, you can just depend on python2 and then run /usr/bin/python2 in the ebuild to use it. Since python is slotted, that works fine. You can also have multiple slots of GCC installed... but they don't all work at the same time! You can't just run e.g. /usr/bin/gcc-7.3 and have it do something useful. Only the version selected by gcc-config is actually usable. That's why the "official" way to depend on a particular version or feature of GCC is to check for it at runtime, and crash if the selected version isn't good enough. We do the same thing if your package needs e.g. OpenMP... see the tc-check-openmp() function in toolchain-funcs.eclass: https://gitweb.gentoo.org/repo/gentoo.git/tree/eclass/toolchain-funcs.eclass So tl;dr you have the right idea but some implementation details get in the way.
Granted, but if I don't even have gcc-7.3 installed I can't invoke it with gcc-config. Even if it's not sensible for the ebuild to flip gcc for itself (and I can think of plenty of reasons that that's a terrible idea), perhaps the dependency itself would at least provide some clue? And/or perhaps check gcc version in pre-merge rather than waiting for src_prepare?
(In reply to Michael Moon from comment #2) > Granted, but if I don't even have gcc-7.3 installed I can't invoke it with > gcc-config. > > Even if it's not sensible for the ebuild to flip gcc for itself (and I can > think of plenty of reasons that that's a terrible idea), perhaps the > dependency itself would at least provide some clue? I've never actually encountered this situation before. Usually all packages in the tree are fixed to work with a new GCC before that version of GCC goes stable. As a result, most of the compiler incompatibilities that we handle manually are when something needs a newer version of GCC (like systemd, for example). > And/or perhaps check gcc version in pre-merge rather than waiting for > src_prepare? Yeah that's preferable, and is usually what we do, although the end result is pretty much the same. Is this still an issue with current versions of TF? Philosophical issues aside, the best thing we could do for the user experience is to make sure that TF builds with the stable and ~arch versions of GCC.
It is not caused by tensorflow itself, but the version of nvcc. This can be handled by cuda_src_prepare() in the cuda.eclass. I will push a fix soon.
