lang/pocl is broken for me for even just clinfo on two independent platforms:
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:
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
#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 ()
#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.
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:
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:
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
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
and another one, which seems unresolved to me, is this one:
Bug 22952: cl::opt + LLVM_BUILD_LLVM_DYLIB is completely broken
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,
Can you re-test this with the last patch in this issue please?
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?