Bug 224584
| Summary: | [PATCH] lang/pocl: fix pkg-plist and update to POCL 1.3 | ||
|---|---|---|---|
| Product: | Ports & Packages | Reporter: | O. Hartmann <ohartmann> |
| Component: | Individual Port(s) | Assignee: | Nikolai Lifanov <lifanov> |
| Status: | Closed FIXED | ||
| Severity: | Affects Many People | CC: | brooks, jcfyecrayz, jmd, lantw44, lbartoletti, lifanov, marcel, ohartmann, rene, swills, w.schwarzenfeld, yuri |
| Priority: | --- | Keywords: | patch |
| Version: | Latest | ||
| Hardware: | Any | ||
| OS: | Any | ||
| See Also: | https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=233495 | ||
| Bug Depends on: | |||
| Bug Blocks: | 231286 | ||
| Attachments: | |||
|
Description
O. Hartmann
2017-12-25 15:07:00 UTC
Maintainer informed via mail *** Bug 224458 has been marked as a duplicate of this bug. *** Hi, I tried to build it without success (patch files aren't applied). Can you double check it? I will put you my patch based on your works. But, there is another problem, pocl crash and tests failed ; maybe my patch is wrong. Thanks. Created attachment 189556 [details]
Update of ohartman works
See also Bug #226092. Created attachment 190869 [details]
lang/pocl: unbreak and update to 1.0
Hi! Have another patch from a duplicate issue (BZ#224584)
o unbreak lang/pocl at package time
o unbreak lang/pocl at runtime
o update lang/pocl to 1.0
o switch to fetching from Github
o switch to LLVM 5.0
o pet portlint
This was tested with security/hashcat on 12.0-CURRENT
*** Bug 226092 has been marked as a duplicate of this bug. *** I'm going to take this bug. O. Hartmann: what's still TODO to move this forward? It definitely compiles and packages fine - so that's progress. It also on executing clinfo look better (none of the previously reported issues) but hangs for me then. I am seeing this issue also elsewhere, so not sure that it's due to this. I honestly think this can go in (assuming maintainer approval) as it is either way an improvement on the current situation. We can then sort whatever bugs appear subsequently? (In reply to Johannes M Dieterich from comment #9) I have no objection with that, although the port isn't very healthy in this state - there is still a serious issue, please see Bug 219562 . When lang/pocl is installed (with devel/ocl-icd) and graphics/blender has been compiled with CYCLES, blender (at the moment R2.79) fails with the same bug as reported in Bug 219562 . Ichecked. It is still present. Also, a very simple peice of code of my own, similar to clinfo, reporting the devices available in the system, fails with the error reported in the forementioned bug. See Bug 219562 for further informations. Anyway, please do not rely on me in this matter! I think I'd go with Johannes M Dieterich opinion that it would be better to have a compiling port so far. Regards Oliver *** Bug 223032 has been marked as a duplicate of this bug. *** POCL 1.1 is out. But according to this bug: http://lists.llvm.org/pipermail/llvm-bugs/2016-October/051237.html the pocl tests fail and so the installation of the port due to this error message: The following tests FAILED: 1 - pocl_version_check (Failed) The version can not be tested, since it fails with message: 1/197 Test #1: pocl_version_check ..................................................................***Failed Required regular expression not found.Regex=[basic] 0.02 sec From POCL USER mailing list, I received word from Michal Babej upon this error and following his instructions (by fixing a csh/sh issue first in the appropriate script of the test performed): [...] Executing # (sh ./tools/scripts/devel-envs.sh && clinfo) gives me Unable to find symbol pthread_mutexattr_setkind_np version (null). Aborting. Abort [...] Well, this, again, and again, seems to be related to this LLVM bug: http://lists.llvm.org/pipermail/llvm-bugs/2016-October/051237.html which I also mentioned in Bug 223032. In my case, it seems graphics/belnder which requires LLVM 4.0 due to openshading language support, but the issue seems tricky as it occurs on FreeBSD whenever another OpenCL platform is also backed via LLVM. In the case for POCL 1.1, I use LLVM 6.0. But the error also shows up with LLVM 5.0. I'm out of ideas, time, mental capabilities. I's like to put the small effords I made (simply adopting the changes to reel in pocl 1.1 instead of pocl 1.0) here to the public, so someone can take a look. Due to the issue mentioned above (LLVM seems not to check for beeing the backend for multiple OpenCL platforms when dynamically linked to those platforms), POCL isn't working properly on FreeBSD with other OpenCL platforms selectable via an ICD like devel/opencl-icd. This sucks :-( Created attachment 192103 [details]
Makefile adapting POCL 1.1
The attached Makefile is a-work-in-progress to adopt POCL 1.1. It is not a replacement for the patch to move to our port to POCL-1.1 since tests fail and therefore the essential pkg-plist updates and checksums aren't in shape.
For your considerations.
*** Bug 224368 has been marked as a duplicate of this bug. *** I had to fix devel/ocl-icd first: somehow linking against pthreads wasn't there, so I had to add a configure option to make it working. Additionally to that, I tried to update to ocl-icd 2.2.12. Hopefully, the patch gets commited soon. Now things regarding lang/pocl are getting a bit confusing. Since there is a serious problem according to a supposedly still remaining bug in LLVM (see http://lists.llvm.org/pipermail/llvm-bugs/2016-October/051237.html), updating to POCL 1.1 is now due to a test suite performed by the pocl source framework blocks installing POCL 1.1 as we know it from POCL 1.0. See Bug 226514. Created attachment 196942 [details]
POCL-1.2-RC2
For your consideration: POCL-1.2-RC2 adaption. Still seeing the bug:
: CommandLine Error: Option 'enable-value-profiling' registered more than once!
LLVM ERROR: inconsistency in registered CommandLine options
What is the status of this? (In reply to Yuri Victorovich from comment #18) POCL 1.2 has been releas on September, 25th. I try to check the port now with LLVM 7.0 as I have hope the nasty bug with multi-registering the very same LLVM backend, which prevents using an ICD (as devel/ocl-icd) has been solved - but I doubt that, since there is no report of any kind of mitigation. My time- and barin-resources in this matter are limited, I regret. VECMATH is going to be deprecated by POCL soon. Also, POCL 1.2 supports HWLOC2, FreeBSD doesn't support HWLOC 2, port devel/hwloc is still HWLOC 1. Maybe this could also be changed soon. Attached, you'll find my latest attempt to maintain the port, with LLVM60 as the default. Created attachment 197659 [details]
Update to POCL 1.2 Release
Update to POCL 1.2, still LLVM60 as default.
Created attachment 197660 [details]
Update to POCL 1.2 official release
My apology for the inconvenience, I needed to obsolete the old files.
The new patch incorporates most of the fixes done by developers herein and the small update by myself.
(In reply to O. Hartmann from comment #21) I tried this attachment and patch-lib_CL_devices_cpuinfo.c doesn't apply for me. Created attachment 197701 [details]
Update POCL 1.2 Release (with LLVM 7.0 as default backend)
Attached, you'll find a corrected patchset. It is for auditing purposes. Enabling LLVM 7.0 as the default backend doesn't solve the error:
X server found. dri2 connection failed!
Device open failed, aborting...
: CommandLine Error: Option 'limited-coverage-experimental' registered more than once!
LLVM ERROR: inconsistency in registered CommandLine options
Nothing to output !
This check was made by devel/clinfo.
(In reply to O. Hartmann from comment #23) I get a similar error if lang/beignet and lang/clover are installed: Simple test case: #include <CL/opencl.h> #include <stdio.h> int main() { unsigned int uu; printf("rc: %d\n", clGetPlatformIDs(0, 0, &uu)); printf("uu: %u\n", uu); return 0; } % cc -Wall -I/usr/local/include -L/usr/local/lib -lOpenCL cl.c -o cl % ./cl X server found. dri2 connection failed! Device open failed, aborting... : CommandLine Error: Option 'enable-value-profiling' registered more than once! LLVM ERROR: inconsistency in registered CommandLine options Nothing to output ! clGetPlatformIDs() apparently is calling exit when it detectes what it thinks is an error (a very impolite think for a library to be doing). Is it expected that beignet and clover should not be installed together for use with OpenCL? See also bug 232357 Is there any reason not to upgrade to LLVM 7.0? AFACT, clinfo issues are irrelevant as it's either missing a required dependency to prevent multiple links to libllvm or it's broken by design. POCL 1.3 is out http://lists.llvm.org/pipermail/llvm-dev/2019-April/131561.html and supports llvm 8.0. Support for llvm <6.0 will be remove in future releases per the release notes. I know, please be patient, update will come shortly. Created attachment 204140 [details]
pocl-1.3 patch (LLVM 8.0 as default)
Attached you'll find a patchfile for lifting pocl to version 1.3 and using by default LLVM 8.0.
The patches' DOCS option doesn't work for now; I also disabled all tests since I had trouble activating and running them properly. Later, I'd like to provide a WIP patchfile with TESTS also being an option.
(In reply to Brooks Davis from comment #26) clinfo is a simple way on pocl-supported FreeBSD platforms to show the pronlem reported in several bugs referenced in this thread. POCL 1.3 in addition with LLVM80 as the backend still emits the error: : CommandLine Error: Option 'limited-coverage-experimental' registered more than once! LLVM ERROR: inconsistency in registered CommandLine options when ocl-icd is used and other device backends, like beignet or clover are installed. I just searched the net for the problem reported with more than one .icd linked to the same LLVM backend (as the aforementioned error indicates),here are some pointing threads I found: LLVM bug: https://bugs.llvm.org/show_bug.cgi?id=30587 POCL: https://github.com/pocl/pocl/issues/474 and another tool (here: Linux): https://github.com/fireice-uk/xmr-stak/issues/1782 The LLVM bug is open since 2016 - almost three years now. As far as I can remember, the problem has been introduced shortly after LLVM 3. POCL once offered a CMAKE arg like -DLLVM_STATIC, replaced by: -DSINGLE_LLVM_LIB when this option is enabled (default), pocl tries to link to a single big LLVM library (libLLVM-<VERSION>.suffix). If this fails, it fallbacks to linking LLVM libraries provided by llvm-config --libfiles. (source: http://portablecl.org/docs/html/install.html) Enriching the above patchfile with CMAKE_ARGS+= -DSINGLE_LLVM_LIB=OFF (it is ON by default as the documentation stats, see above) does not have any influence of the broken behaviour. Created attachment 204838 [details]
pocl-1.3 patch (LLVM 8.0 as default)
After some notifications reported that lang/beignet has been marked DEPRECATED, I started again looking after POCL.
It seems POCL 1.3 compiles fine with -std=c++11, so I got rid of _CXXSTD=gnu++11.
After the deletion of lang/beignet from all FreeBSD CURRENT systems I run I was finally able to run "clinfo" successfully without any errors.
Please check.
A commit references this bug: Author: brooks Date: Thu Jun 6 21:07:43 UTC 2019 New revision: 503602 URL: https://svnweb.freebsd.org/changeset/ports/503602 Log: Update to POCL 1.3. PR: 224584 Submitted by: ohartmann@walstatt.org (maintainer) Changes: head/lang/pocl/Makefile head/lang/pocl/distinfo head/lang/pocl/files/patch-CMakeLists.txt head/lang/pocl/files/patch-config.h.in.cmake head/lang/pocl/files/patch-lib_CL_devices_cpuinfo.c head/lang/pocl/files/patch-lib_CL_pocl__binary.c head/lang/pocl/files/patch-tests_regression_test__issue__445.cpp head/lang/pocl/pkg-descr head/lang/pocl/pkg-plist There is a problem with the recent lang/pocl pkg-plist description in the ports tree compared to the patch I sent. My local/personal poudriere fails to register the port after building with this error: [...] =======================<phase: package >============================ ===> Building package for pocl-1.3 pkg-static: Unable to access file /wrkdirs/usr/ports/lang/pocl/work/stage/usr/local/share/pocl/kernel-x86_64-portbld-freebsd12.2-avx.bc:No such file or directory pkg-static: Unable to access file /wrkdirs/usr/ports/lang/pocl/work/stage/usr/local/share/pocl/kernel-x86_64-portbld-freebsd12.2-avx2.bc:No such file or directory pkg-static: Unable to access file /wrkdirs/usr/ports/lang/pocl/work/stage/usr/local/share/pocl/kernel-x86_64-portbld-freebsd12.2-avx512.bc:No such file or directory pkg-static: Unable to access file /wrkdirs/usr/ports/lang/pocl/work/stage/usr/local/share/pocl/kernel-x86_64-portbld-freebsd12.2-avx_f16c.bc:No such file or directory pkg-static: Unable to access file /wrkdirs/usr/ports/lang/pocl/work/stage/usr/local/share/pocl/kernel-x86_64-portbld-freebsd12.2-avx_fma4.bc:No such file or directory pkg-static: Unable to access file /wrkdirs/usr/ports/lang/pocl/work/stage/usr/local/share/pocl/kernel-x86_64-portbld-freebsd12.2-sse2.bc:No such file or directory pkg-static: Unable to access file /wrkdirs/usr/ports/lang/pocl/work/stage/usr/local/share/pocl/kernel-x86_64-portbld-freebsd12.2-sse41.bc:No such file or directory pkg-static: Unable to access file /wrkdirs/usr/ports/lang/pocl/work/stage/usr/local/share/pocl/kernel-x86_64-portbld-freebsd12.2-ssse3.bc:No such file or directory *** Error code 1 [...] On my CURRENT as well as my 12-STABLE poudriere platform, there is no line like "%%DATADIR%%/kernel-%%ARCH%%-portbld-%%PYTHON_PLATFORM%%.2-avx.bc" in pkg-plist as it is now in the ports tree. When running "make makeplist", it is always "%%DATADIR%%/kernel-%%ARCH%%-portbld-%%PYTHON_PLATFORM%%.0-avx.bc" (no .2, it is .0 as it is in the patchfile I've sent.). Did I miss something? (In reply to O. Hartmann from comment #34) I'm getting this error too. (In reply to Yuri Victorovich from comment #35) The commited patch deviates from the patchfile I sent in that way, that in pkg-plist, the rows [...] %%DATADIR%%/kernel-%%ARCH%%-portbld-%%PYTHON_PLATFORM%%.0-avx.bc %%DATADIR%%/kernel-%%ARCH%%-portbld-%%PYTHON_PLATFORM%%.0-avx2.bc %%DATADIR%%/kernel-%%ARCH%%-portbld-%%PYTHON_PLATFORM%%.0-avx512.bc %%DATADIR%%/kernel-%%ARCH%%-portbld-%%PYTHON_PLATFORM%%.0-avx_f16c.bc %%DATADIR%%/kernel-%%ARCH%%-portbld-%%PYTHON_PLATFORM%%.0-avx_fma4.bc %%DATADIR%%/kernel-%%ARCH%%-portbld-%%PYTHON_PLATFORM%%.0-sse2.bc %%DATADIR%%/kernel-%%ARCH%%-portbld-%%PYTHON_PLATFORM%%.0-sse41.bc %%DATADIR%%/kernel-%%ARCH%%-portbld-%%PYTHON_PLATFORM%%.0-ssse3.bc has been (magically?) replaced by [...] %%DATADIR%%/kernel-%%ARCH%%-portbld-%%PYTHON_PLATFORM%%.2-avx.bc %%DATADIR%%/kernel-%%ARCH%%-portbld-%%PYTHON_PLATFORM%%.2-avx2.bc %%DATADIR%%/kernel-%%ARCH%%-portbld-%%PYTHON_PLATFORM%%.2-avx512.bc %%DATADIR%%/kernel-%%ARCH%%-portbld-%%PYTHON_PLATFORM%%.2-avx_f16c.bc %%DATADIR%%/kernel-%%ARCH%%-portbld-%%PYTHON_PLATFORM%%.2-avx_fma4.bc %%DATADIR%%/kernel-%%ARCH%%-portbld-%%PYTHON_PLATFORM%%.2-sse2.bc %%DATADIR%%/kernel-%%ARCH%%-portbld-%%PYTHON_PLATFORM%%.2-sse41.bc %%DATADIR%%/kernel-%%ARCH%%-portbld-%%PYTHON_PLATFORM%%.2-ssse3.bc On my platforms running make/poudriere, %%PYTHON_PLATFORM%% expands to either freebsd11, freebsd12 or freebsd13 and the port appends always ".0"; I did not digg deeper into this, but I guess it's always ".0" on FreeBSD (while it might be relevant on Linux or other platforms I do not care for). Be aware of the fact that the documentation is not build as it it suggested by the port. I have some trouble solving the problem due to time constraints. (In reply to O. Hartmann from comment #36) It was .2 for me. I don't know why. I'll look into this tomorrow when my test machine is hopefully back online (building power outage). A commit references this bug: Author: brooks Date: Wed Jun 12 19:57:21 UTC 2019 New revision: 504035 URL: https://svnweb.freebsd.org/changeset/ports/504035 Log: Correct plist file. The previous entries stem from trusting over-zealous substitution in check-plist output. PR: 224584 Changes: head/lang/pocl/Makefile head/lang/pocl/pkg-plist Closing this for PR 231286 (llvm40 removal), I believe this port is fixed? Feel free to open a new PR if not ;) |
