On 30 August 2017 at 13:12, Tamas Berghammer via lldb-dev
wrote:
> I tried to build using the following command what should be a reasonably
> close approximation to the one you used (I don't have ICU installed at the
> moment) and it still links fine for me:
> CC=/usr/bin/clang CXX=/usr/bin/clang+
I tried to build using the following command what should be a reasonably
close approximation to the one you used (I don't have ICU installed at the
moment) and it still links fine for me:
CC=/usr/bin/clang CXX=/usr/bin/clang++ cmake -G Ninja ../../llvm
-DBUILD_SHARED_LIBS=true -DLLVM_TARGETS_TO_BUI
Hi Tamas,
It looks like lldb-server only fails if I build with a Debug configuration,
which I didn't realize until now. In Release configuration, I don't need any
changes to CMakefiles and lldb-server links without error. My full build
configuration in debug mode was:
mkdir lldb50.1708110153
Hi Peeter,
Why do you have to make the dependency conditional on
BUILD_SHARED_LIBS? If lldbExpression
depends on LLVMRuntimeDyld it should depend on it independently of the
build config.
Also I gave it a try to build lldb using shared libraries locally and I
haven't hit any issue when I used the
Hi Tamas,
I was able to use your suggestion as follows:
diff --git a/source/Expression/CMakeLists.txt b/source/Expression/CMakeLists.txt
index 7d9643a..b53b095 100644
--- a/source/Expression/CMakeLists.txt
+++ b/source/Expression/CMakeLists.txt
@@ -2,6 +2,12 @@ if(NOT LLDB_BUILT_STANDALONE)
Hi All,
We are trying to keep the size of lldb-server as small as possible as it
have to be copied over to the android device for every debug session. The
way we currently achieve this is by using linker garbage collection to get
rid of the unused code.
In the log term it would be nice to be more
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 jus
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
Looks like a dependency issue in LLVM? Who was using this function? Why do we
need LLVMRuntimeDyld in lldb-server? We shouldn't have to use it. I know we
currently have some issues in lldb-server where it is pulling in too much
stuff, so we definitely don't want to include this just to fix a lin
I've built lldb in tree on Linux (RHEL 7.3) with a shared library configuration:
CC=/usr/bin/clang CXX=/usr/bin/clang++ \
cmake -G Ninja ../llvm \
-DBUILD_SHARED_LIBS=true \
...
The lldb-server binary does not link for me, as I get unresolved symbols
including:
llvm::RuntimeDyld::MemoryManag
10 matches
Mail list logo
