If we are pulling in the expression parser, that would explain our issues. If this currently happens in lldb-server we need to add LLVMRuntimeDyld to the link libraries. I know some people at Google have looked into getting lldb-server to link against as little as possible, and maybe this is just how things are for the time being. We should verify that. It would be nice if lldb-server didn't link against the expression parser if possible.
Greg > On Aug 28, 2017, at 9:56 AM, Peeter Joot <peeterj...@protonmail.com> wrote: > > Hi Greg, > > IRExecutionUnit.cpp looks like the origin of at least some of the undefined > symbols: > > .../llvm/include/llvm/ExecutionEngine/RTDyldMemoryManager.h:61: undefined > reference to `vtable for llvm::RTDyldMemoryManager' > > > .../llvm/include/llvm/ExecutionEngine/JITSymbol.h:223: undefined reference to > `vtable for llvm::JITSymbolResolver' > > > .../llvm/include/llvm/ExecutionEngine/RuntimeDyld.h:96: undefined reference > to `vtable for llvm::RuntimeDyld::MemoryManager' > > > lib/liblldbExpression.a(IRExecutionUnit.cpp.o):(.data.rel.ro+0x90): undefined > reference to `llvm::RTDyldMemoryManager::deregisterEHFrames()' > > lib/liblldbExpression.a(IRExecutionUnit.cpp.o):(.data.rel.ro+0xa8): undefined > reference to `llvm::RuntimeDyld::MemoryManager::anchor()' > > lib/liblldbExpression.a(IRExecutionUnit.cpp.o):(.data.rel.ro+0x118): > undefined reference to `llvm::JITSymbolResolver::anchor()' > > lib/liblldbExpression.a(IRExecutionUnit.cpp.o):(.data.rel.ro._ZTVN4llvm18MCJITMemoryManagerE[_ZTVN4llvm18MCJITMemoryManagerE]+0x60): > undefined reference to `llvm::RuntimeDyld: > > :MemoryManager::anchor()' > > > there are a couple of undefined vtable references in headers (also above), > but it's not clear to me if these also neccessarily come from > IRExectionUnix.cpp. > > -- > Peeter > >
_______________________________________________ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
