This is new... portage-utils now fails in catalyst stage3 with "Enable OpemMP support by building sys-devel/gcc with USE='openmp'". Reproducible: Always Steps to Reproduce: 1. Download latest stage3 from gentoo to use as seed 2. catalyst -af stage1.spec && catalyst -af stage2.spec && catalyst -af stage3.spec Actual Results: catalyst -af stage3.spec fails Expected Results: gcc should already be compiled with openmp.
Just an observation... chrooted into my stage3 dir. emerge --pretend portage-utils does pull in gcc[openmp]. It seems like pkg_pretend stops the emerge from proceeding even though gcc would get recompiled with openmp before getting to portage-utils.
This new openmp handling was introduced in commit 152cba16dd90e36b4e8abd4c4445adee321a37d3 https://bugs.gentoo.org/867076 is the source for that, point 3 mentions the OpenMP part. @soap do you have any thoughts on what's going on here?
(In reply to Damien Moody (audiodef) from comment #0) I think the problem lies with your catalyst-based process. You may need to alter it to rebuild gcc with the required USE flags.
Also, moving the tc-check-openmp from pkg_pretend to pkg_setup in the portage-utils ebuild would probably help here.
Right, the OpenMP dep is necessary-but-not-sufficient, so we should add it. pkg_pretend vs pkg_setup (or both) is hard because pkg_pretend may fail even if GCC is queued for a rebuild to enable OpenMP before portage-utils. (We've had various issues with the linux-headers check in the glibc ebuild, for example, with this.)
(In reply to Mike Gilbert from comment #3) > (In reply to Damien Moody (audiodef) from comment #0) > > I think the problem lies with your catalyst-based process. You may need to > alter it to rebuild gcc with the required USE flags. Could be! I've been trying to figure out how. Haven't been successful so far with a modified portage-utils ebuild. The other thing I'm thinking about is scripting a dive into the stage2 to rebuild gcc. Catalyst would then start stage3 with gcc[openmp] done. (I thought it was already supposed to be that way, though, but I'm not l337.)
(In reply to Sam James from comment #5) > Right, the OpenMP dep is necessary-but-not-sufficient, so we should add it. Based on reading the tc-check-openmp function, the dep would need to be something like: || ( sys-devel/gcc[openmp] sys-libs/libomp ) If we added a clang USE flag, we could be more specific. !clang? ( sys-devel/gcc[openmp] ) clang? ( sys-libs/libomp ) It might be good idea to add a virtual for this to avoid repeating it across any package that needs openmp support.
Has there been any movement on this? I was forced to resolve it by masking newer versions of portage-utils, but this issue is still stopping my catalyst builds.
Can you force -openmp for portage-utils to work around this during this stage? I doubt you'll really need multi-threading support at this point.
I noted that older versions of portage-utils had no pkg_pretend stage, so I pushed a modified version of the current portage-utils to Gentoo Studio's overlay without pkg_pretend. It compiled successfully in stage3.
Hit the same bug. tc-check-openmp fails because of absence of omp.h /tmp # cat t.c === #include <omp.h> int main(void) { int nthreads, tid, ret = 0; #pragma omp parallel private(nthreads, tid) { tid = omp_get_thread_num(); nthreads = omp_get_num_threads(); ret += tid + nthreads; } return ret; } /tmp # gcc -fopenmp t.c t.c:1:10: fatal error: omp.h: No such file or directory 1 | #include <omp.h> | ^~~~~~~ compilation terminated. === If file omp.h is placed into <chroot_base>/usr/include and libgomp.* into <chroot_base>/usr/lib building continues. Not sure how to check if gcc really has openmp support.
(In reply to Fabian Groffen from comment #9) > Can you force -openmp for portage-utils to work around this during this > stage? I doubt you'll really need multi-threading support at this point. Do you mind if I add the dep suggested in comment #7 and remove the pkg_pretend check, so that gcc gets queued for rebuild for +openmp (or libomp is queued for install) and is ready by the time pkg_setup is run? Thanks
(In reply to Ben Kohler from comment #12) > (In reply to Fabian Groffen from comment #9) > > Can you force -openmp for portage-utils to work around this during this > > stage? I doubt you'll really need multi-threading support at this point. > > Do you mind if I add the dep suggested in comment #7 and remove the > pkg_pretend check, so that gcc gets queued for rebuild for +openmp (or > libomp is queued for install) and is ready by the time pkg_setup is run? > > Thanks QA added the current code in 152cba16dd90e36b4e8abd4c4445adee321a37d3. Before that, the code looked somewhat like the suggestion, e.g. ec3307e507ccfc092371f8e16ea40ff50557ca9f. That said, I'm not going to stop you, but in my experience QA is not flexible, and I expect you to deal with them if the need should arise.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=c9f4376eb1b1ac1134fa71e74c52b53c594635c2 commit c9f4376eb1b1ac1134fa71e74c52b53c594635c2 Author: Ben Kohler <bkohler@gentoo.org> AuthorDate: 2023-06-28 15:02:30 +0000 Commit: Ben Kohler <bkohler@gentoo.org> CommitDate: 2023-06-29 19:57:26 +0000 app-portage/portage-utils: make best effort to get gcc[openmp] installed Bug: https://bugs.gentoo.org/890752 Signed-off-by: Ben Kohler <bkohler@gentoo.org> .../portage-utils/portage-utils-0.95-r1.ebuild | 75 ++++++++++++++++++++++ .../portage-utils/portage-utils-0.96-r1.ebuild | 75 ++++++++++++++++++++++ .../portage-utils/portage-utils-9999.ebuild | 8 +-- 3 files changed, 154 insertions(+), 4 deletions(-)
assuming sufficiently fixed
