OpenCL runtimes and LLVM command line options

Hello everyone,

A while back I hit an issue where the presence of multiple OpenCL runtimes
on a single system triggered errors in libLLVM caused by redeclaring
command line arguments [0]. There's been some discussion on the bug report and
a pointer to a slightly older report, unrelated to OpenCL, but most likely
about the same issue [1].

OpenCL uses an ICD loader library to abstract away the installed runtimes.
That way, applications can link against the ICD loader instead of the actual
runtimes, which makes it more portable. This does also allow distributions to
ship support for all the various OpenCL runtimes out there.

The problem is that some OpenCL runtimes link libclangCodeGen statically
(where the offending cli arguments are defined), and libLLVM dynamically.

The ICD loader has to load every runtime on the system in order to determine
which one to use. When an affected runtime is loaded, it registers the cli
arguments from the static libclangCodeGen in the dynamic libLLVM. If another
runtime is loaded that tries to do the same, the check in libLLVM triggers and
aborts program execution.

The practical effect that users see is, once multiple OpenCL runtimes are
installed on one system any OpenCL-enabled application aborts on start with an
LLVM error. Needless to say this is a less than desirable situation.

There are currently multiple workarounds for this problem, each with its own
set of drawbacks. Debian decided to statically link libLLVM [2], OpenSUSE
decided to build all clang libs also as shared libraries (using
BUILD_SHARED_LIBS=ON) [3] and Red Hat has an open issue about it in their bug
tracker [4].

Since this issue has been present for a rather long time without clear
solution or recommendation for a workaround, I'd like to bring this some more
attention in the hopes of fixing this.

Grs,
Heinz

[0] https://bugs.llvm.org/show_bug.cgi?id=30587
[1] https://bugs.llvm.org/show_bug.cgi?id=22952
[2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=852746
[3] https://bugzilla.opensuse.org/show_bug.cgi?id=1065464
[4] https://bugzilla.redhat.com/show_bug.cgi?id=1565659

We have a similar problem in Mesa's radeonsi driver. It would be great if command-line options could somehow be tied to an llvm::Context, for example.

There is an even worse problem when *different versions* of LLVM are loaded into the same process. This is basically guaranteed to lead to crashes because of symbol clashes. I wonder if C++11 inline namespaces could be used for proper versioning. I admit I haven't given it too much thought.

Cheers,
Nicolai

We have a similar problem in Mesa's radeonsi driver. It would be great if command-line options could somehow be tied to an llvm::Context, for example.

There is an even worse problem when *different versions* of LLVM are loaded into the same process. This is basically guaranteed to lead to crashes because of symbol clashes. I wonder if C++11 inline namespaces could be used for proper versioning. I admit I haven't given it too much thought.

Does enabling symbol versioning in LLVM fix this?

-Tom

We have a similar problem in Mesa's radeonsi driver. It would be great if command-line options could somehow be tied to an llvm::Context, for example.

There is an even worse problem when *different versions* of LLVM are loaded into the same process. This is basically guaranteed to lead to crashes because of symbol clashes. I wonder if C++11 inline namespaces could be used for proper versioning. I admit I haven't given it too much thought.

Does enabling symbol versioning in LLVM fix this?

*goes to check cmake*

Oh, you mean LLVM_DYLIB_SYMBOL_VERSIONING? That sounds plausible, but I've never tried it... why is that off by default?

Thanks,
Nicolai

We have a similar problem in Mesa's radeonsi driver. It would be great if command-line options could somehow be tied to an llvm::Context, for example.

There is an even worse problem when *different versions* of LLVM are loaded into the same process. This is basically guaranteed to lead to crashes because of symbol clashes. I wonder if C++11 inline namespaces could be used for proper versioning. I admit I haven't given it too much thought.

Does enabling symbol versioning in LLVM fix this?

*goes to check cmake*

Oh, you mean LLVM_DYLIB_SYMBOL_VERSIONING? That sounds plausible, but I've never tried it... why is that off by default?

Symbol versioning should be enabled be default. That option has been obsoleted,
so it shouldn't be necessary.

-Tom