[llvm-dev] OpenCL runtimes and LLVM command line options

[Nicolai Hähnle via llvm-dev]

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

On 06.05.2018 13:05, Heinz Wiesinger via llvm-dev wrote:
> 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
> 
> 
> 
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
> 


-- 
Lerne, wie die Welt wirklich ist,
Aber vergiss niemals, wie sie sein sollte.