|Summary:||lang/pocl: crash during initialization|
|Product:||Ports & Packages||Reporter:||Johannes M Dieterich <jmd>|
|Component:||Individual Port(s)||Assignee:||freebsd-ports-bugs mailing list <ports-bugs>|
|Status:||Closed Feedback Timeout|
|Severity:||Affects Only Me||CC:||lifanov, mandree, ohartmann, w.schwarzenfeld|
|Bug Depends on:||233495|
Description Johannes M Dieterich 2017-05-26 01:39:01 UTC
lang/pocl is broken for me for even just clinfo on two independent platforms: on Carrizo: $ clinfo CommandLine Error: Option 'enable-value-profiling' registered more than once! LLVM ERROR: inconsistency in registered CommandLine options on a Broadwell EP dual socket it gets a bit further: $ clinfo Number of platforms 1 Platform Name Portable Computing Language Platform Vendor The pocl project Platform Version OpenCL 2.0 pocl 0.14, LLVM 4.0.1 Platform Profile FULL_PROFILE Platform Extensions cl_khr_icd Platform Extensions function suffix POCL Segmentation fault (core dumped) Quick gdb (sorry, no debug symbols) points to libhwloc (gdb) bt #0 0x0000000802d26075 in ?? () from /usr/local/lib/libhwloc.so.5 #1 0x0000000802d25f2d in ?? () from /usr/local/lib/libhwloc.so.5 #2 0x0000000802d25a77 in ?? () from /usr/local/lib/libhwloc.so.5 #3 0x0000000802d0c95b in hwloc_topology_load () from /usr/local/lib/libhwloc.so.5 #4 0x0000000801722923 in ?? () from /usr/local/lib/libpocl.so.1.7.0 #5 0x000000080171e8ec in ?? () from /usr/local/lib/libpocl.so.1.7.0 #6 0x00000008017193f3 in ?? () from /usr/local/lib/libpocl.so.1.7.0 #7 0x00000008016f1fc4 in ?? () from /usr/local/lib/libpocl.so.1.7.0 #8 0x0000000800839a4a in clGetDeviceIDs () from /usr/local/lib/libOpenCL.so.1 #9 0x0000000000401fb9 in ?? () #10 0x0000000000409867 in ?? () #11 0x000000000040151f in ?? () #12 0x0000000800633000 in ?? () #13 0x0000000000000000 in ?? ()
Comment 1 Bugzilla Automation 2017-05-26 01:39:01 UTC
Maintainer informed via mail
Comment 2 Jan Beich 2017-08-27 19:11:04 UTC
What FreeBSD version/architecture? If -CURRENT then update as some dlopen() issues have been fixed a few months ago. Otherwise, build lang/pocl and everything from LIB_DEPENDS with debugging symbols (i.e., pass WITH_DEBUG=1) then show "bt" (or "bt full") output again.
Comment 3 Johannes M Dieterich 2017-10-20 03:28:11 UTC
Had tested on later HEAD amd64 machines: carrizo, threadripper, broadwell EP architectures. Same issue in all cases (if I recall correctly): segfaults. Currently the package does not build for me, so can't do more testing right now. Let me ask the other way round: on which architectures have you successfully run the current version (where "run" can be as primitive as "exec clinfo")?
Comment 4 O. Hartmann 2017-10-20 06:57:40 UTC
I have already submitted a proposal for a patch (PR 223032). I do not have modern and sophisticated architectures at hand. But I realise some serious issues with older OCL software which successfully ran a while ago on CURRENT which is not on recent builds.
Comment 5 O. Hartmann 2017-11-26 09:04:00 UTC
Hello. My last statement reflects that I didn't got the problem, sorry for that. We ran into a similar problem with graphics/blender these days were OpenCL is enabled. I stumbled over this report: https://github.com/pocl/pocl/issues/474 On boxes where I have installesd mesa-lib and beignet as well, pocl doesn't work. Blender doesn't work either. With #223032 I submitted a patch making lang/pocl build again - but I have never tested it against build environments depending on gcc and I guess the issue in PR 0223032 is only fixed for clang builds. So I need help on this, please.
Comment 6 O. Hartmann 2017-11-26 09:11:41 UTC
Just for the record, this one is on the LLVM bug list: http://lists.llvm.org/pipermail/llvm-bugs/2016-October/051237.html
Comment 7 O. Hartmann 2017-12-25 12:35:02 UTC
I just try to update our port from pocl 0.14 to pocl 1.0, since pocl-1.0 is out for a couple of days now. The problem the initial poster faced is still persistent and I was searching the net for some solutions. I'm not a compiler expert and my resources are limited. I tried compiling lang/pocl with the option by setting SINGLE_LLVM_LIB=ON via cmake, but this put a considerable load and compile time to the port build I do not want to bear. Searching the bug databse at LLVM.ORG, I found some references to this type of bug, but at different places and I'm wondering if this is still with FreeBSD's implementation of CLANG/LLVM. [...] Don't link ObjCARCOpts twice. Fixes PR22543 https://reviews.llvm.org/rL240104 and another one, which seems unresolved to me, is this one: [...] Bug 22952: cl::opt + LLVM_BUILD_LLVM_DYLIB is completely broken https://bugs.llvm.org/show_bug.cgi?id=22952 Since I use on most recent CURRENT still the default linker, which is ld.bfd, I have not checked whether this problem is still with the LLVM/CLANG ld.lld linker, since using the new linker causes a lot of trouble with important ports. It would be great if someone with a more decent insight into this LLVM linker stuff could take a look. Thanks in advance, oh
Comment 8 Nikolai Lifanov 2018-02-21 20:21:43 UTC
Can you re-test this with the last patch in this issue please? https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=224584 The patch updates pocl to 1.0 and llvm to 5.0, and I'm no longer seeing the crash.
Comment 9 Walter Schwarzenfeld 2018-03-05 19:32:03 UTC
@ O. Hartmann Please, change mail address in Makefile.
Comment 10 Walter Schwarzenfeld 2019-08-11 13:27:12 UTC
pocl version is 1.3, llvm default is llvm90. Is this still relevant?