Summary: | media-libs/mesa-18.2.2-r1 and dev-libs/ocl-icd-2.2.12 and app-eselect/eselect-opencl-1.1.0-r4 and virtual/opencl-0-r5 - /usr/include/CL contains broken symlinks | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Dennis Schridde <dschridde+gentoobugs> |
Component: | Current packages | Assignee: | Gentoo X packagers <x11> |
Status: | RESOLVED TEST-REQUEST | ||
Severity: | normal | CC: | adia, creideiki+gentoo-bugzilla, eugene.shalygin, jano.vesely, proteuss, uleysky, viklevin2 |
Priority: | Normal | Keywords: | PullRequest |
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
See Also: |
https://bugs.gentoo.org/show_bug.cgi?id=605576 https://github.com/gentoo/gentoo/pull/10122 |
||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: |
wine build log
ocl-icd build log |
Description
Dennis Schridde
2018-10-09 09:00:25 UTC
Possibly related: $ sudo eselect opencl set mesa !!! Error: The mesa OpenCL implementation doesn't seem to provide !!! Error: libOpenCL.so file. This might be an effect of breakage introduced !!! Error: by a prioprietary driver installer. Please re-merge the package !!! Error: providing your OpenCL implementation. !!! Error: Selected OpenCL implementation incomplete. exiting Something weird is going on with Mesa 18.2.2-r1 and bug #546320. I no longer have any OpenCL include files, either from media-libs/mesa-18.2.2-r1 or dev-libs/ocl-icd-2.2.12. Looking at the ebuild, the code for installing the headers seems to have been deliberately removed from -r1, but I can't see what it's supposed to have been replaced with: root@luna mesa # diff -u mesa-18.2.2.ebuild mesa-18.2.2-r1.ebuild [...] @@ -488,21 +486,6 @@ multilib_src_install() { meson_src_install - - if use opencl; then - ebegin "Moving Gallium/Clover OpenCL implementation for dynamic switching" - local cl_dir="/usr/$(get_libdir)/OpenCL/vendors/mesa" - dodir ${cl_dir}/{lib,include} - if [ -f "${ED}/usr/$(get_libdir)/libOpenCL.so" ]; then - mv -f "${ED}"/usr/$(get_libdir)/libOpenCL.so* \ - "${ED}"${cl_dir} - fi - if [ -f "${ED}/usr/include/CL/opencl.h" ]; then - mv -f "${ED}"/usr/include/CL \ - "${ED}"${cl_dir}/include - fi - eend $? - fi } Cc'ing Jan. (In reply to Matt Turner from comment #3) > Cc'ing Jan. Look's like the problem is that ocl-icd is an opencl provider but does not provide CL headers. (In reply to Jan Vesely from comment #4) > (In reply to Matt Turner from comment #3) > > Cc'ing Jan. > > Look's like the problem is that ocl-icd is an opencl provider but does not > provide CL headers. That is because app-eselect/eselect-opencl-1.1.0-r4 itself provides them: # q file -v /usr/lib64/OpenCL/global/include/CL-* app-eselect/eselect-opencl-1.1.0-r4 (/usr/lib64/OpenCL/global/include/CL-1.0) app-eselect/eselect-opencl-1.1.0-r4 (/usr/lib64/OpenCL/global/include/CL-1.1) app-eselect/eselect-opencl-1.1.0-r4 (/usr/lib64/OpenCL/global/include/CL-1.2) app-eselect/eselect-opencl-1.1.0-r4 (/usr/lib64/OpenCL/global/include/CL-2.0) app-eselect/eselect-opencl-1.1.0-r4 (/usr/lib64/OpenCL/global/include/CL-2.1) Apparently it was just forgotten to link one of them into the right location (/usr/include/CL). (In reply to Dennis Schridde from comment #5) > (In reply to Jan Vesely from comment #4) > > (In reply to Matt Turner from comment #3) > > > Cc'ing Jan. > > > > Look's like the problem is that ocl-icd is an opencl provider but does not > > provide CL headers. > > That is because app-eselect/eselect-opencl-1.1.0-r4 itself provides them: > # q file -v /usr/lib64/OpenCL/global/include/CL-* > app-eselect/eselect-opencl-1.1.0-r4 (/usr/lib64/OpenCL/global/include/CL-1.0) > app-eselect/eselect-opencl-1.1.0-r4 (/usr/lib64/OpenCL/global/include/CL-1.1) > app-eselect/eselect-opencl-1.1.0-r4 (/usr/lib64/OpenCL/global/include/CL-1.2) > app-eselect/eselect-opencl-1.1.0-r4 (/usr/lib64/OpenCL/global/include/CL-2.0) > app-eselect/eselect-opencl-1.1.0-r4 (/usr/lib64/OpenCL/global/include/CL-2.1) > > Apparently it was just forgotten to link one of them into the right location > (/usr/include/CL). That would be another solution. https://github.com/gentoo/gentoo/pull/10122 modifies ocl-icd to install khronos headers, dunno which one is preferred. Not sure how the dependency graph actually looks like, but wouldn't it be easier to structure it like this? virtual/opencl depends on: - media-libs/opencl-headers - dev-libs/ocl-icd # loader - one of: # actual implementation - media-libs/mesa - ... media-libs/opencl-headers-1.2:0 (e.g.) would contain the official Khronos OpenCL headers for OpenCL 1.2 in /usr/include/CL. app-eselect/eselect-opencl would no longer be necessary, since the libraries would be selected at runtime by dev-libs/ocl-icd and the headers would be selected at installation time using the slot for media-libs/opencl-headers. You could even have multiple virtual/opencl versions, each depending on the corresponding media-libs/opencl-headers package and only those implementations (or versions thereof) that support this version of OpenCL. (In reply to Dennis Schridde from comment #7) > Not sure how the dependency graph actually looks like, but wouldn't it be > easier to structure it like this? > > virtual/opencl depends on: > - media-libs/opencl-headers > - dev-libs/ocl-icd # loader > - one of: # actual implementation > - media-libs/mesa > - ... > > media-libs/opencl-headers-1.2:0 (e.g.) would contain the official Khronos > OpenCL headers for OpenCL 1.2 in /usr/include/CL. > app-eselect/eselect-opencl would no longer be necessary, since the libraries > would be selected at runtime by dev-libs/ocl-icd and the headers would be > selected at installation time using the slot for media-libs/opencl-headers. > > You could even have multiple virtual/opencl versions, each depending on the > corresponding media-libs/opencl-headers package and only those > implementations (or versions thereof) that support this version of OpenCL. I'm not sure about the metric for 'easier', it would require modifications of all packages providing opencl implementation. Restricting loader to ocl-icd and droping ocl-icd sounds appealing (Matt proposed something like that in the original PR[0]), but: a) we need to be sure that all opencl implementatoins can provide ICD b) there is no reason to ever prefer other loaders than ocl-icd [0] https://github.com/gentoo/gentoo/pull/9836 (In reply to Jan Vesely from comment #8) > I'm not sure about the metric for 'easier', it would require modifications > of all packages providing opencl implementation. I guess this largely depends on how many OpenCL implementations we have. If it was just a handful, I wouldn't think it's too much work. > Restricting loader to ocl-icd and droping ocl-icd ? (In reply to Dennis Schridde from comment #9) > (In reply to Jan Vesely from comment #8) > > I'm not sure about the metric for 'easier', it would require modifications > > of all packages providing opencl implementation. > > I guess this largely depends on how many OpenCL implementations we have. If > it was just a handful, I wouldn't think it's too much work. it's mostly about testing, and checking that there is no reason (like a special feature) to prefer other loader. I counted 5 packages that provide opencl implementation (and depend on ocl-icd): dev-libs/amdgpu-pro-opencl dev-libs/beignet (this one is on life support upstream, dunno if anyone is looking into packaging NEO) dev-util/intel-ocl-sdk media-libs/mesa x11-drivers/nvidia-drivers I was mainly interested in mesa, because mesa opencl can't load other ICD drivers. afaik both intel-ocl-sdk and beignet can (I've never used the other implementations) > > Restricting loader to ocl-icd and droping ocl-icd > > ? dropping eselect-opencl of course ocl-icd-2.2.12[khronos-headers] should fix this (In reply to Jan Vesely from comment #11) > ocl-icd-2.2.12[khronos-headers] should fix this But it does not. Building wine: configure: error: OpenCL development files not found, OpenCL won't be supported. This is an error since --with-opencl was requested. # eselect opencl list Available OpenCL implementations: [1] ocl-icd * $ eix ocl-icd | grep Installed Installed versions: 2.2.12(23:12:40 2018-10-20)(khronos-headers ABI_MIPS="-n32 -n64 -o32" ABI_PPC="-32 -64" ABI_S390="-32 -64" ABI_X86="64 -32 -x32") (In reply to Eugene Shalygin from comment #12) > (In reply to Jan Vesely from comment #11) > > ocl-icd-2.2.12[khronos-headers] should fix this > > But it does not. Building wine: > > configure: error: OpenCL development files not found, OpenCL won't be > supported. > This is an error since --with-opencl was requested. > > # eselect opencl list > > Available OpenCL implementations: > [1] ocl-icd * > > $ eix ocl-icd | grep Installed > Installed versions: 2.2.12(23:12:40 2018-10-20)(khronos-headers > ABI_MIPS="-n32 -n64 -o32" ABI_PPC="-32 -64" ABI_S390="-32 -64" ABI_X86="64 > -32 -x32") can you post the result of `ls -l /usr/include/CL` and the build log of ocl-icd[khronos-headers]? ls -l /usr/include/CL total 28 lrwxrwxrwx 1 root root 50 Oct 20 23:12 cl.h -> ../../lib64/OpenCL/vendors/ocl-icd/include/CL/cl.h lrwxrwxrwx 1 root root 49 Dec 1 2017 cl_egl.h -> //usr/lib64/OpenCL/global/include/CL-1.2/cl_egl.h lrwxrwxrwx 1 root root 54 Oct 20 23:12 cl_ext.h -> ../../lib64/OpenCL/vendors/ocl-icd/include/CL/cl_ext.h lrwxrwxrwx 1 root root 53 Oct 20 23:12 cl_gl.h -> ../../lib64/OpenCL/vendors/ocl-icd/include/CL/cl_gl.h lrwxrwxrwx 1 root root 57 Oct 20 23:12 cl_gl_ext.h -> ../../lib64/OpenCL/vendors/ocl-icd/include/CL/cl_gl_ext.h lrwxrwxrwx 1 root root 59 Oct 20 23:12 cl_platform.h -> ../../lib64/OpenCL/vendors/ocl-icd/include/CL/cl_platform.h lrwxrwxrwx 1 root root 54 Oct 20 23:12 opencl.h -> ../../lib64/OpenCL/vendors/ocl-icd/include/CL/opencl.h Created attachment 552086 [details]
wine build log
Created attachment 552088 [details]
ocl-icd build log
(In reply to Eugene Shalygin from comment #14) > ls -l /usr/include/CL > total 28 > lrwxrwxrwx 1 root root 50 Oct 20 23:12 cl.h -> > ../../lib64/OpenCL/vendors/ocl-icd/include/CL/cl.h > lrwxrwxrwx 1 root root 49 Dec 1 2017 cl_egl.h -> > //usr/lib64/OpenCL/global/include/CL-1.2/cl_egl.h > lrwxrwxrwx 1 root root 54 Oct 20 23:12 cl_ext.h -> > ../../lib64/OpenCL/vendors/ocl-icd/include/CL/cl_ext.h > lrwxrwxrwx 1 root root 53 Oct 20 23:12 cl_gl.h -> > ../../lib64/OpenCL/vendors/ocl-icd/include/CL/cl_gl.h > lrwxrwxrwx 1 root root 57 Oct 20 23:12 cl_gl_ext.h -> > ../../lib64/OpenCL/vendors/ocl-icd/include/CL/cl_gl_ext.h > lrwxrwxrwx 1 root root 59 Oct 20 23:12 cl_platform.h -> > ../../lib64/OpenCL/vendors/ocl-icd/include/CL/cl_platform.h > lrwxrwxrwx 1 root root 54 Oct 20 23:12 opencl.h -> > ../../lib64/OpenCL/vendors/ocl-icd/include/CL/opencl.h This looks like the broken symlinks are fixed. (In reply to Eugene Shalygin from comment #15) > Created attachment 552086 [details] > wine build log Even wine finds them (from the log): > checking CL/cl.h usability... yes > checking CL/cl.h presence... yes > checking for CL/cl.h... yes The problem is in linking to libOpenCL.so: > checking for clGetPlatformInfo in -lOpenCL... no > configure: error: OpenCL development files not found, OpenCL won't be supported. > This is an error since --with-opencl was requested. which is expected since the error happens in 32bit configure: > * abi_x86_32.x86: running multilib-minimal_abi_src_configure but you didn't build ocl-icd with 32bit support: > $ eix ocl-icd | grep Installed > Installed versions: 2.2.12(23:12:40 2018-10-20)(khronos-headers ABI_MIPS="-n32 -n64 -o32" ABI_PPC="-32 -64" ABI_S390="-32 -64" ABI_X86="64 -32 -x32") I was happy to help you to locate a problem in either app-emulation/wine-any or virtual/opencl ebuild. (In reply to Eugene Shalygin from comment #18) > I was happy to help you to locate a problem in either app-emulation/wine-any > or virtual/opencl ebuild. actually, it's neither. These patches https://github.com/gentoo/gentoo/pull/10209 should help address it. If not please open a new bug report. (In reply to Eugene Shalygin from comment #18) > I was happy to help you to locate a problem in either app-emulation/wine-any > or virtual/opencl ebuild. mesa-18.2.3 should now correctly pull in 32bit ocl-icd |