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 ?? ()
Maintainer informed via mail
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.
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")?
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.
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.
Just for the record, this one is on the LLVM bug list: http://lists.llvm.org/pipermail/llvm-bugs/2016-October/051237.html
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
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.
@ O. Hartmann Please, change mail address in Makefile.
pocl version is 1.3, llvm default is llvm90. Is this still relevant?