LLVM 5.0 comes with special library lookup ordering options.

Force using the old behavior and explain why it is not so good idea.
This commit is contained in:
Vassil Vassilev 2017-10-21 19:02:49 +02:00 committed by sftnight
parent d6fe62edaf
commit 985b2c8740

View File

@ -282,6 +282,22 @@ IncrementalJIT::IncrementalJIT(IncrementalExecutor& exe,
m_CompileLayer(m_ObjectLayer, llvm::orc::SimpleCompiler(*m_TM)), m_CompileLayer(m_ObjectLayer, llvm::orc::SimpleCompiler(*m_TM)),
m_LazyEmitLayer(m_CompileLayer) { m_LazyEmitLayer(m_CompileLayer) {
// Force the JIT to query for symbols local to itself, i.e. if it resides in a
// shared library it will resolve symbols from there first. This is done to
// implement our proto symbol versioning protection. Namely, if some other
// library provides llvm symbols, we want out JIT to avoid looking at them.
//
// FIXME: In general, this approach causes numerous issues when cling is
// embedded and the framework needs to provide its own set of symbols which
// exist in llvm. Most notably if the framework links against different
// versions of linked against llvm libraries. For instance, if we want to provide
// a custom zlib in the framework the JIT will still resolve to llvm's version
// of libz causing hard-to-debug bugs. In order to work around such cases we
// need to swap the llvm system libraries, which can be tricky for two
// reasons: (a) llvm's cmake doesn't really support it; (b) only works if we
// build llvm from sources.
llvm::sys::DynamicLibrary::SearchOrder
= llvm::sys::DynamicLibrary::SO_LoadedFirst;
// Enable JIT symbol resolution from the binary. // Enable JIT symbol resolution from the binary.
llvm::sys::DynamicLibrary::LoadLibraryPermanently(0, 0); llvm::sys::DynamicLibrary::LoadLibraryPermanently(0, 0);