This package fails to compile on an unstable system. Attached relevant logs and emerge --info
Created attachment 707685 [details] emerge_info emerge --info
Created attachment 707688 [details] rocm-opencl-runtime-4.1.0:20210512-174553.log build log
I am getting the same error. If I downgrade to dev-util/opencl-headers-2020.12.18 then this package is able to build again. This also fixes bug 789558
Same issue here. Downgrading to opencl-headers-2020.06.16 also resolves it.
Same here. The missing include seems to be in dev-libs/rocclr so I tried: ``` --- ROCclr-rocm-4.1.0/platform/command.hpp 2021-02-16 14:17:07.000000000 -0800 +++ ROCclr-rocm-4.1.0-new/platform/command.hpp 2021-06-22 00:38:11.868378194 -0700 @@ -44,6 +44,7 @@ #include "platform/activity.hpp" #include "CL/cl_ext.h" +#include "CL/cl_gl.h" #include <algorithm> #include <atomic> ``` to no avail. And now it seems like stable opencl-headers isn't in tree anymore so I have to dig it out of the graveyard.
rocm-opencl-runtime has its own private cl_ext.h which is like the old version. Both wind up getting involved in the same .c compile invocation and they step on each other's toes leading to a big ugly mess. There is an upstream PR for this with a patch that ostensibly works for gentoo. It's a pretty big and scary patch and upstream didn't seem receptive to it for reasons which, as I recall, seemed kinda sus., but, ultimately, I wasn't knowledgeable enough to decide if they made sense or not. That patch is available at: https://github.com/RadeonOpenCompute/ROCm-OpenCL-Runtime/commit/f3e27f81adbed599baa2e34214ea19c84362f946.patch it's too large to post in a gentoo bug, even compressed :) Mostly due to deletions of large header files. So in short this patch will probably get you building and may or may not break your opencl. Personally I applied it. But I'm not really using opencl for much so... ymmv. Maybe the newer headers should simply be masked by the ebuild instead of applying this patch.
(In reply to Greg Turner from comment #6) > rocm-opencl-runtime has its own private cl_ext.h which is like the old > version. Both wind up getting involved in the same .c compile invocation > and they step on each other's toes leading to a big ugly mess. > > There is an upstream PR for this with a patch that ostensibly works for > gentoo. It's a pretty big and scary patch and upstream didn't seem > receptive to it for reasons which, as I recall, seemed kinda sus., but, > ultimately, I wasn't knowledgeable enough to decide if they made sense or > not. That patch is available at: > > > https://github.com/RadeonOpenCompute/ROCm-OpenCL-Runtime/commit/ > f3e27f81adbed599baa2e34214ea19c84362f946.patch > > it's too large to post in a gentoo bug, even compressed :) Mostly due to > deletions of large header files. > > So in short this patch will probably get you building and may or may not > break your opencl. Personally I applied it. But I'm not really using > opencl for much so... ymmv. Maybe the newer headers should simply be masked > by the ebuild instead of applying this patch. just a note, as I recall the patch doesn't apply cleanly and will require some trivial merging by hand. But IIRC it really was quite trivial to merge, just a couple of hunks rejected with easy, pretty obvious solutions.
Created attachment 719319 [details, diff] Patch from comment #6 with conflicts resolved
Created attachment 719322 [details, diff] Extra patch that didn't apply with f3e27f81.patch
(In reply to Greg Turner from comment #7) > (In reply to Greg Turner from comment #6) > > That patch is available at: > > > > > > https://github.com/RadeonOpenCompute/ROCm-OpenCL-Runtime/commit/ > > f3e27f81adbed599baa2e34214ea19c84362f946.patch > > just a note, as I recall the patch doesn't apply cleanly and will require > some trivial merging by hand. But IIRC it really was quite trivial to > merge, just a couple of hunks rejected with easy, pretty obvious solutions. Whew, finally got it to apply. It is attached, as is a second patch I had to break out of the big one for some reason? Must have confused something while hand-editing the big patch. Anyways, it applies, but doesn't build because they've edited a bunch of things into their bundled version of Khronos headers, so it can't compile with system headers. Will attach a build log of that too.
Created attachment 719325 [details] Failed build log after applying f3e27f81.patch
Created attachment 719343 [details, diff] rocm-30x-to-rocm-31x.patch (In reply to A Schenck from comment #11) > Created attachment 719325 [details] > Failed build log after applying f3e27f81.patch Hm, I wonder why... I forget the story behind it, but I have another patch applied to rocm-comgr... I wonder if that is what makes the difference somehow? I've attached the patch. sigh, so confusing...
Regardless of whether that works or not, this path feels pretty dead-end-ish. The fact is upstream is having none of that patch -- now that you mention it I think that's the reason they cited for not accepting it, that they had some special sauce in their headers. But then why did it work for me? bleh. My impression was upstream just doesn't intend to support recent opencl, at least not yet... which means the Gentoo gets to choose between masking recent or maintaining a temporary fork until upstream gets its act together.
Hehehe, after rebuilding world I now suffer from exactly the error you have, A.Schenck! Oh well it was a nice illusion while it lasted :(
Personally I have locally masked the versions >4.0.0 and requested stabilization for v 4.0.0
Created attachment 719490 [details, diff] opencl-3.0-header-compat.patch A new approach that might actually work: this literally occurred to me while showering so it has to be good! It's far less intrusive than the other patch and seems to do the trick on my box. My only concerns are: will it work for everybody? And does it depend on the rocm-30x-to-rocm-31x rocm-comgr patch somehow? Basically the idea is, at all costs, prevent the mixing of the 3.0 and 2.2 headers in any given compile step.
Same thing happens now with 4.2.0. I'll help with testing. In file included from /usr/include/vdi_common.hpp:26, from /var/tmp/portage/dev-libs/rocm-opencl-runtime-4.2.0/work/ROCm-OpenCL-Runtime-rocm-4.2.0/amdocl/cl_common.hpp:32, from /var/tmp/portage/dev-libs/rocm-opencl-runtime-4.2.0/work/ROCm-OpenCL-Runtime-rocm-4.2.0/amdocl/cl_platform_amd.cpp:21: /usr/include/rocclr/platform/command.hpp: In constructor ‘amd::ClGlEvent::ClGlEvent(amd::Context&)’: /usr/include/rocclr/platform/command.hpp:330:41: error: ‘CL_COMMAND_GL_FENCE_SYNC_OBJECT_KHR’ was not declared in this scope; did you mean ‘CL_COMMAND_EGL_FENCE_SYNC_OBJECT_KHR’?
The opencl-3.0 patch applies and rocm-opencl-runtime-4.2.0 compiles OK.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=ef8e8e2845f17f827461f86f37c415a02d842f4b commit ef8e8e2845f17f827461f86f37c415a02d842f4b Author: Patrick Lauer <patrick@gentoo.org> AuthorDate: 2021-06-30 05:38:27 +0000 Commit: Patrick Lauer <patrick@gentoo.org> CommitDate: 2021-06-30 05:39:44 +0000 dev-libs/rocm-opencl-runtime: Fix building with newer opencl-headers Bug: https://bugs.gentoo.org/789717 Package-Manager: Portage-3.0.20, Repoman-3.0.3 Signed-off-by: Patrick Lauer <patrick@gentoo.org> .../rocm-opencl-runtime-4.2.0-opencl3-header.patch | 65 ++++++++++++++++++++++ .../rocm-opencl-runtime-4.2.0.ebuild | 1 + 2 files changed, 66 insertions(+)
