Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 703272 - sci-libs/tensorflow-2.1.0_rc0 requires <=sys-devel/gcc-7.3 but ebuild does not list this dependency
Summary: sci-libs/tensorflow-2.1.0_rc0 requires <=sys-devel/gcc-7.3 but ebuild does no...
Status: UNCONFIRMED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: Jason Zaman
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2019-12-18 08:44 UTC by Michael Moon
Modified: 2020-03-26 02:00 UTC (History)
3 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Michael Moon 2019-12-18 08:44:57 UTC
"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
Comment 1 Michael Orlitzky gentoo-dev 2020-02-17 02:19:52 UTC
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.
Comment 2 Michael Moon 2020-02-17 22:03:38 UTC
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?
Comment 3 Michael Orlitzky gentoo-dev 2020-02-18 17:10:38 UTC
(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.
Comment 4 Benda Xu gentoo-dev 2020-03-26 02:00:38 UTC
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.