I have come across this issue when trying to use a self-built current
development version of pocl on by Debian sid machine with rusticl
installed, and is caused by multiple concurrent factors.

For work, I need to build the pocl CUDA backend, which refuses to build
against llvm 21 because of this bug

https://github.com/llvm/llvm-project/issues/154772

that has apparently been fixed in this LLVM commit:

https://github.com/llvm/llvm-project/pull/170170

The issue manifests differently depending on which version of rusticl I
have installed and how pocl is built. Some of the combinations I've
tried are:

mesa-opencl-icd 25.3.3-1, custom pocl built against llvm 18:
running some OpenCL programs on the rusticl platform segfaults in the
constructor for clang::DiagnosticOptions, called by
clc_compile_to_llvm_module from clc.

mesa-opencl-icd 25.3.3-1, custom pocl built against llvm 19,
mesa-opencl-icd 26.0.0~rc3, custom pocl built against llvm 18:
segfault is triggered in the rusticl platform devices enumeration during
a full `clinfo` when the rusticl platform tries to build the simple
kernels used to check preferred workgroup size multiples.

mesa-opencl-icd 25.3.3-1, custom pocl built against llvm 18 with
-DSTATIC_LLVM=ON: crashes `clinfo -l` during the pocl device
numeration, with the well-known

: CommandLine Error: Option 'internalize-public-api-file' registered more than once! LLVM ERROR: inconsistency in registered CommandLine options

error (wow, I hadn't seen this in a LONG time).

While I can probably provisionally solve my specific issue by
downgrading my mesa-opencl-icd installation to the stabl version, which
is built against LLVM 19, or possibly by a backport of the
aforementioned 170170 PR to the LLVM 21 in Debian, the underlying issue
remains that it is still impossible to have multiple OpenCL ICD versions
using different LLVM / libclang versions in the same system.