Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 669368 - =app-eselect/eselect-opencl-1.1.0-r4: src_install no longer creates cl.hpp symlink (but should)
Summary: =app-eselect/eselect-opencl-1.1.0-r4: src_install no longer creates cl.hpp sy...
Status: RESOLVED OBSOLETE
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: Gentoo X packagers
URL:
Whiteboard:
Keywords:
Depends on: 728284
Blocks:
  Show dependency tree
 
Reported: 2018-10-23 00:41 UTC by Daniel M. Weeks
Modified: 2020-09-12 21:15 UTC (History)
3 users (show)

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


Attachments
clhpp-2.0.10.ebuild (clhpp-2.0.10.ebuild,933 bytes, text/plain)
2018-11-18 22:30 UTC, Jan Vesely
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Daniel M. Weeks 2018-10-23 00:41:14 UTC
Older revisions created a symlink for cl.hpp. I can not find an explanation for why this was dropped but typical C++ OpenCL applications include "CL/cl.hpp" so this breaks them.

Reproducible: Always
Comment 1 Matt Turner gentoo-dev 2018-10-30 14:05:09 UTC
Jan, is this still a problem?
Comment 2 Jan Vesely 2018-10-31 13:24:16 UTC
(In reply to Matt Turner from comment #1)
> Jan, is this still a problem?

I've never run into this, but it looks like it's still a problem:

> $ ls /usr/include/CL
> cl_egl.h  cl_ext.h  cl_gl_ext.h  cl_gl.h  cl.h  cl_platform.h  opencl.h

at least ocl-icd does not provide cl.hpp:

> $ ls /usr/lib64/OpenCL/vendors/ocl-icd/include/CL/
> cl_d3d10.h  cl_dx9_media_sharing.h  cl_ext.h     cl_gl.h  cl_platform.h
> cl_d3d11.h  cl_egl.h                cl_gl_ext.h  cl.h     opencl.h

and eselect-opencl only provides cl.hpp for OCL 2.1:
> $ ls /usr/lib64/OpenCL/global/include/*
> /usr/lib64/OpenCL/global/include/CL-1.0:
> cl_ext.h  cl_gl_ext.h  cl_gl.h  cl.h  cl_platform.h  opencl.h
> 
> /usr/lib64/OpenCL/global/include/CL-1.1:
> cl_ext.h  cl_gl_ext.h  cl_gl.h  cl.h  cl_platform.h  opencl.h
> 
> /usr/lib64/OpenCL/global/include/CL-1.2:
> cl_egl.h  cl_ext.h  cl_gl_ext.h  cl_gl.h  cl.h  cl_platform.h  opencl.h
> 
> /usr/lib64/OpenCL/global/include/CL-2.0:
> cl_egl.h  cl_ext.h  cl_gl_ext.h  cl_gl.h  cl.h  cl_platform.h  opencl.h
> 
> /usr/lib64/OpenCL/global/include/CL-2.1:
> cl_egl.h  cl_ext.h  cl_gl_ext.h  cl_gl.h  cl.h  cl.hpp  cl_platform.h  opencl.h

I don't know when and how select-opencl decides to headers from /global/.

Note that Khronos does not include cl.hpp in its headers https://github.com/KhronosGroup/OpenCL-Headers
but in a separate project
https://github.com/KhronosGroup/OpenCL-CLHPP

we can patch ocl-icd (and all other ocl providers that miss the header) to provide cl.hpp.
however, given that the c++ bindings are not a core part of ocl specs, perhaps we should add a new clhpp package that can provide the header on top of any OCL provider?
Comment 3 Daniel M. Weeks 2018-11-01 14:27:13 UTC
I think there's some history here that's significant but I don't know all of it. What I've gathered is many projects used to include specific versions of the OpenCL headers in their own source trees and it caused a lot of problems at the system level. Gentoo packaged them once in eselect-opencl and the global directory worked around a lot of those problems.

Now, Khronos has version-independent headers broken out into repos for both C and C++. Many projects seem to have dropped their in-tree headers in favor of those repos. I'll expand on what Jan said and suggest that it may be time for Gentoo to re-evaluate packaging the headers in eselect-opencl and instead package them more like upstream.
Comment 4 Jan Vesely 2018-11-03 16:51:29 UTC
(In reply to Daniel M. Weeks from comment #3)
> I think there's some history here that's significant but I don't know all of
> it. What I've gathered is many projects used to include specific versions of
> the OpenCL headers in their own source trees and it caused a lot of problems
> at the system level. Gentoo packaged them once in eselect-opencl and the
> global directory worked around a lot of those problems.
> 
> Now, Khronos has version-independent headers broken out into repos for both
> C and C++. Many projects seem to have dropped their in-tree headers in favor
> of those repos. I'll expand on what Jan said and suggest that it may be time
> for Gentoo to re-evaluate packaging the headers in eselect-opencl and
> instead package them more like upstream.

thanks. I'm not sure where that leaves us. Is anyone still maintaining eselect-opencl?
should we:
a) drop eselect-opencl and let ocl-icd provide khronos headers (including cl.hpp)
b) drop eselect-opencl and let a separate package/s (dev-libs/opencl-headers, dev-libs/opencl-cpp-headers) provide ocl headers (including cl.hpp). virtual/opencl and dev-libs/ocl-icd can depend on those.
c) keep eselect-opencl and fix it to provide khronos headers unless there is an ocl (loader) provider that includes custom headers (possibly with vendor specific extensions)
Comment 5 Matt Turner gentoo-dev 2018-11-03 17:24:25 UTC
(In reply to Jan Vesely from comment #4)
> (In reply to Daniel M. Weeks from comment #3)
> > I think there's some history here that's significant but I don't know all of
> > it. What I've gathered is many projects used to include specific versions of
> > the OpenCL headers in their own source trees and it caused a lot of problems
> > at the system level. Gentoo packaged them once in eselect-opencl and the
> > global directory worked around a lot of those problems.
> > 
> > Now, Khronos has version-independent headers broken out into repos for both
> > C and C++. Many projects seem to have dropped their in-tree headers in favor
> > of those repos. I'll expand on what Jan said and suggest that it may be time
> > for Gentoo to re-evaluate packaging the headers in eselect-opencl and
> > instead package them more like upstream.
> 
> thanks. I'm not sure where that leaves us. Is anyone still maintaining
> eselect-opencl?

No, I don't think so. Getting rid of it and using ocl-icd is best.

> should we:
> a) drop eselect-opencl and let ocl-icd provide khronos headers (including
> cl.hpp)
> b) drop eselect-opencl and let a separate package/s
> (dev-libs/opencl-headers, dev-libs/opencl-cpp-headers) provide ocl headers
> (including cl.hpp). virtual/opencl and dev-libs/ocl-icd can depend on those.

Dropping eselect-opencl seems best. I don't have a preference on whether ocl-icd provides the headers. I assume opencl headers don't change very often, so providing the headers in ocl-icd seems okay. If they do change relatively often, a single separate package would be good. I don't see the need for separate c/c++ header packages.
Comment 6 Jan Vesely 2018-11-18 22:30:47 UTC
Created attachment 555680 [details]
clhpp-2.0.10.ebuild

(In reply to Matt Turner from comment #5)
> (In reply to Jan Vesely from comment #4)
> > (In reply to Daniel M. Weeks from comment #3)
> > > I think there's some history here that's significant but I don't know all of
> > > it. What I've gathered is many projects used to include specific versions of
> > > the OpenCL headers in their own source trees and it caused a lot of problems
> > > at the system level. Gentoo packaged them once in eselect-opencl and the
> > > global directory worked around a lot of those problems.
> > > 
> > > Now, Khronos has version-independent headers broken out into repos for both
> > > C and C++. Many projects seem to have dropped their in-tree headers in favor
> > > of those repos. I'll expand on what Jan said and suggest that it may be time
> > > for Gentoo to re-evaluate packaging the headers in eselect-opencl and
> > > instead package them more like upstream.
> > 
> > thanks. I'm not sure where that leaves us. Is anyone still maintaining
> > eselect-opencl?
> 
> No, I don't think so. Getting rid of it and using ocl-icd is best.
> 
> > should we:
> > a) drop eselect-opencl and let ocl-icd provide khronos headers (including
> > cl.hpp)
> > b) drop eselect-opencl and let a separate package/s
> > (dev-libs/opencl-headers, dev-libs/opencl-cpp-headers) provide ocl headers
> > (including cl.hpp). virtual/opencl and dev-libs/ocl-icd can depend on those.
> 
> Dropping eselect-opencl seems best. I don't have a preference on whether
> ocl-icd provides the headers. I assume opencl headers don't change very
> often, so providing the headers in ocl-icd seems okay. If they do change
> relatively often, a single separate package would be good. I don't see the
> need for separate c/c++ header packages.

I think it'd be easier to provide a clhpp package than trying to mix ocl-icd and Khronos OpenCL-CLHPP in one ebuild. Moreover, the build process should generate cl.hpp cl2.hpp to match the current CL headers.

How does the attached ebuild (dev-libs/clhpp) look?
Comment 7 Jan Vesely 2019-03-20 05:43:17 UTC
ping.

any thought on the new clhpp package?
Comment 8 Matt Turner gentoo-dev 2019-04-07 21:04:43 UTC
(In reply to Jan Vesely from comment #7)
> ping.
> 
> any thought on the new clhpp package?

Oops, sorry this fell off my radar. The ebuild looks good. Want to make a pull request on github with this and whatever other changes are required?
Comment 9 Jan Vesely 2019-04-25 23:20:04 UTC
(In reply to Matt Turner from comment #8)
> (In reply to Jan Vesely from comment #7)
> > ping.
> > 
> > any thought on the new clhpp package?
> 
> Oops, sorry this fell off my radar. The ebuild looks good. Want to make a
> pull request on github with this and whatever other changes are required?

https://github.com/gentoo/gentoo/pull/11827

I've checked that neither mesa nor beignet nor nvidia-drivers nor intel-ocl-sdk include these headers.
Comment 10 Matt Turner gentoo-dev 2019-04-26 18:10:26 UTC
(In reply to Jan Vesely from comment #9)
> (In reply to Matt Turner from comment #8)
> > (In reply to Jan Vesely from comment #7)
> > > ping.
> > > 
> > > any thought on the new clhpp package?
> > 
> > Oops, sorry this fell off my radar. The ebuild looks good. Want to make a
> > pull request on github with this and whatever other changes are required?
> 
> https://github.com/gentoo/gentoo/pull/11827
> 
> I've checked that neither mesa nor beignet nor nvidia-drivers nor
> intel-ocl-sdk include these headers.

Thank you. I've merged that PR.
Comment 11 nE0sIghT 2020-03-06 16:44:07 UTC
Don't virtual/opencl should depend on dev-libs/clhpp?
Comment 12 Jan Vesely 2020-04-30 20:37:35 UTC
(In reply to nE0sIghT from comment #11)
> Don't virtual/opencl should depend on dev-libs/clhpp?

Probably not by default, C++ headers are separate from OpenCL, but maybe it can add a cxx useflag