Currently building with cmake -DBUILD_SHARED_LIBS=ON on Linux x86-64 results in: lib/liblldbHost.a(Host.cpp.o): In function `lldb_private::Host::RunShellCommand(char const*, char const*, int*, int*, std:: __1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >*, unsigned int, bool)': /home/abuild/rpmbuild/BUILD/llvm/stage2/../tools/lldb/source/Host/common/Host.cpp:578: warning: the use of `mktemp' is dang erous, better use `mkstemp' lib/liblldbExpression.a(ClangExpressionParser.cpp.o): In function `ClangExpressionParser': /home/abuild/rpmbuild/BUILD/llvm/stage2/../tools/lldb/source/Expression/ClangExpressionParser.cpp:127: undefined reference to `llvm::sys::getDefaultTargetTriple()' lib/liblldbExpression.a(ClangExpressionParser.cpp.o): In function `lldb_private::ClangExpressionParser::Parse(lldb_private: :Stream&)': /home/abuild/rpmbuild/BUILD/llvm/stage2/../tools/lldb/source/Expression/ClangExpressionParser.cpp:315: undefined reference to `llvm::sys::fs::createTemporaryFile(llvm::Twine const&, llvm::StringRef, int&, llvm::SmallVectorImpl<char>&)' /home/abuild/rpmbuild/BUILD/llvm/stage2/../tools/lldb/source/Expression/ClangExpressionParser.cpp:311: undefined reference to `llvm::sys::fs::createUniqueFile(llvm::Twine const&, int&, llvm::SmallVectorImpl<char>&, unsigned int)' /home/abuild/rpmbuild/BUILD/llvm/stage2/../tools/lldb/source/Expression/ClangExpressionParser.cpp:339: undefined reference to `llvm::MemoryBuffer::getMemBufferCopy(llvm::StringRef, llvm::Twine const&)' tools/lldb/tools/lldb-gdbserver/CMakeFiles/lldb-gdbserver.dir/__/__/source/lldb.cpp.o: In function `lldb_private::Initializ e()': /home/abuild/rpmbuild/BUILD/llvm/stage2/../tools/lldb/source/lldb.cpp:130: undefined reference to `llvm::install_fatal_erro r_handler(void (*)(void*, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&, bool), void* )' [lots of similar errors] Static builds work fine.
Created attachment 13396 [details] Fixes the build when BUILD_SHARED_LIBS is set This seems to fix the build when BUILD_SHARED_LIBS=ON.
(In reply to comment #1) > Created attachment 13396 [details] > Fixes the build when BUILD_SHARED_LIBS is set > > This seems to fix the build when BUILD_SHARED_LIBS=ON. Hi, with the above patch we get to the next linker error as shown below. thx Michi [ 4703s] FAILED: : && /home/abuild/rpmbuild/BUILD/llvm-3.6.0.git.1416975074.568f7e8/stage1/bin/clang++ -fPIC -fvisibility-inlines-hidden -Wall -W -Wno-unused-parameter -Wwrite-strings -Wcast-qual -Wmissing-field-initializers -pedantic -Wno-long-long -Wcovered-switch-default -Wnon-virtual-dtor -std=c++11 -fcolor-diagnostics -ffunction-sections -fdata-sections -Wno-deprecated-declarations -Wno-unknown-pragmas -Wno-deprecated-register -fno-exceptions -fno-rtti -O3 -DNDEBUG -Wl,-allow-shlib-undefined -Wl,-O3 -Wl,--gc-sections tools/lldb/tools/lldb-platform/CMakeFiles/lldb-platform.dir/lldb-platform.cpp.o -o bin/lldb-platform-3.6.0 lib/liblldb.so.3.6.0 lib/libLLVMX86CodeGen.so.3.6.0 lib/libLLVMX86AsmPrinter.so.3.6.0 lib/libLLVMX86AsmParser.so.3.6.0 lib/libLLVMX86Desc.so.3.6.0 lib/libLLVMX86Info.so.3.6.0 lib/libLLVMX86Disassembler.so.3.6.0 lib/libLLVMInterpreter.so.3.6.0 lib/libLLVMAsmParser.so.3.6.0 lib/libLLVMBitReader.so.3.6.0 lib/libLLVMBitWriter.so.3.6.0 lib/libLLVMCodeGen.so.3.6.0 lib/libLLVMipo.so.3.6.0 lib/libLLVMSelectionDAG.so.3.6.0 lib/libLLVMMC.so.3.6.0 lib/libLLVMMCJIT.so.3.6.0 lib/libLLVMCore.so.3.6.0 lib/libLLVMMCDisassembler.so.3.6.0 lib/libLLVMExecutionEngine.so.3.6.0 lib/libLLVMOption.so.3.6.0 lib/libLLVMSupport.so.3.6.0 -Wl,--start-group lib/liblldbBreakpoint.a lib/liblldbCommands.a lib/liblldbDataFormatters.a lib/liblldbHost.a lib/liblldbCore.a lib/liblldbExpression.a lib/liblldbInterpreter.a lib/liblldbSymbol.a lib/liblldbTarget.a lib/liblldbUtility.a lib/liblldbPluginDisassemblerLLVM.a lib/liblldbPluginSymbolFileDWARF.a lib/liblldbPluginSymbolFileSymtab.a lib/liblldbPluginDynamicLoaderStatic.a lib/liblldbPluginDynamicLoaderPosixDYLD.a lib/liblldbPluginDynamicLoaderHexagonDYLD.a lib/liblldbPluginObjectFileMachO.a lib/liblldbPluginObjectFileELF.a lib/liblldbPluginObjectFileJIT.a lib/liblldbPluginSymbolVendorELF.a lib/liblldbPluginObjectContainerBSDArchive.a lib/liblldbPluginObjectContainerMachOArchive.a lib/liblldbPluginProcessGDBRemote.a lib/liblldbPluginProcessMachCore.a lib/liblldbPluginProcessUtility.a lib/liblldbPluginPlatformGDB.a lib/liblldbPluginPlatformFreeBSD.a lib/liblldbPluginPlatformKalimba.a lib/liblldbPluginPlatformLinux.a lib/liblldbPluginPlatformPOSIX.a lib/liblldbPluginPlatformWindows.a lib/liblldbPluginPlatformMacOSX.a lib/liblldbPluginDynamicLoaderMacOSXDYLD.a lib/liblldbPluginUnwindAssemblyInstEmulation.a lib/liblldbPluginUnwindAssemblyX86.a lib/liblldbPluginAppleObjCRuntime.a lib/liblldbPluginCXXItaniumABI.a lib/liblldbPluginABIMacOSX_arm.a lib/liblldbPluginABIMacOSX_arm64.a lib/liblldbPluginABIMacOSX_i386.a lib/liblldbPluginABISysV_x86_64.a lib/liblldbPluginABISysV_hexagon.a lib/liblldbPluginABISysV_ppc.a lib/liblldbPluginABISysV_ppc64.a lib/liblldbPluginInstructionARM.a lib/liblldbPluginInstructionARM64.a lib/liblldbPluginObjectFilePECOFF.a lib/liblldbPluginOSPython.a lib/liblldbPluginMemoryHistoryASan.a lib/liblldbPluginInstrumentationRuntimeAddressSanitizer.a lib/liblldbAPI.a lib/liblldbPluginProcessLinux.a lib/liblldbPluginProcessPOSIX.a lib/liblldbPluginProcessElfCore.a lib/liblldbPluginJITLoaderGDB.a -Wl,--end-group lib/libclangAnalysis.so.3.6.0 lib/libclangAST.so.3.6.0 lib/libclangBasic.so.3.6.0 lib/libclangCodeGen.so.3.6.0 lib/libclangDriver.so.3.6.0 lib/libclangEdit.so.3.6.0 lib/libclangFrontend.so.3.6.0 lib/libclangLex.so.3.6.0 lib/libclangParse.so.3.6.0 lib/libclangRewrite.so.3.6.0 lib/libclangRewriteFrontend.so.3.6.0 lib/libclangSema.so.3.6.0 lib/libclangSerialization.so.3.6.0 -Wl,-rpath,"\$ORIGIN/../lib64" && : [ 4703s] lib/liblldbPluginProcessGDBRemote.a(GDBRemoteCommunicationServer.cpp.o): In function `GDBRemoteCommunicationServer::Handle_qProcessInfo(StringExtractorGDBRemote&)': [ 4703s] ../tools/lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServer.cpp:(.text._ZN28GDBRemoteCommunicationServer19Handle_qProcessInfoER24StringExtractorGDBRemote+0x13c): undefined reference to `llvm::Triple::getOSName() const' [ 4703s] ../tools/lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServer.cpp:(.text._ZN28GDBRemoteCommunicationServer19Handle_qProcessInfoER24StringExtractorGDBRemote+0x27c): undefined reference to `llvm::Triple::isArch64Bit() const' [ 4703s] ../tools/lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServer.cpp:(.text._ZN28GDBRemoteCommunicationServer19Handle_qProcessInfoER24StringExtractorGDBRemote+0x291): undefined reference to `llvm::Triple::isArch32Bit() const' [ 4703s] ../tools/lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServer.cpp:(.text._ZN28GDBRemoteCommunicationServer19Handle_qProcessInfoER24StringExtractorGDBRemote+0x2a6): undefined reference to `llvm::Triple::isArch16Bit() const' [ 4703s] clang-3.6: error: linker command failed with exit code 1 (use -v to see invocation) [ 4709s] ninja: build stopped: subcommand failed.
(In reply to comment #2) > (In reply to comment #1) > > Created attachment 13396 [details] > > Fixes the build when BUILD_SHARED_LIBS is set > > > > This seems to fix the build when BUILD_SHARED_LIBS=ON. > > Hi, > > with the above patch we get to the next linker error as shown below. Also looks like lldb-mi must link to pthread, so Index: llvm/tools/lldb/tools/lldb-mi/CMakeLists.txt =================================================================== --- llvm.orig/tools/lldb/tools/lldb-mi/CMakeLists.txt +++ llvm/tools/lldb/tools/lldb-mi/CMakeLists.txt @@ -164,7 +164,7 @@ add_lldb_executable(lldb-mi ) endif () -target_link_libraries(lldb-mi liblldb) +target_link_libraries(lldb-mi liblldb pthread) # TODO: why isn't this done by add_lldb_executable? #target_link_libraries(lldb-mi ${LLDB_USED_LIBS}) #llvm_config(lldb-mi ${LLVM_LINK_COMPONENTS}) is also needed
I can't seem to replicate the need for pthread or the linker error after the patch. Can you post how your cmake is configured?
(In reply to comment #4) > I can't seem to replicate the need for pthread or the linker error after the > patch. Can you post how your cmake is configured? pthread seems to be needed due to libc++ which we can fix later on, but the problem from comment #2 seems to be someting else. For me this is a llvm+clang+lldb+libcxx+libcxxabi build with: cmake -G "Ninja" \ -DBUILD_SHARED_LIBS=ON \ -DCMAKE_BUILD_TYPE=RelWithDebInfo \ -DCMAKE_INSTALL_PREFIX=%{_prefix} \ -DLLVM_LIBDIR_SUFFIX=64 \ -DLLVM_REQUIRES_RTTI=ON \ -DLLVM_ENABLE_TIMESTAMPS=OFF \ -DLLVM_ENABLE_ASSERTIONS=ON \ -DLLVM_ENABLE_PIC=ON \ -DLLVM_BINUTILS_INCDIR=/usr/include \ -DLLVM_TARGETS_TO_BUILD=all \ -DLLVM_ENABLE_FFI=ON \ -DLLVM_INCLUDE_TESTS=OFF \ -DLLVM_ENABLE_LIBCXX=ON \ ..
Created attachment 13403 [details] change all lldb modules to compile as shared library when BUILD_SHARED_LIBS is set. The problem seems to be that most of the lldb modules are still compiled as static library even if BUILD_SHARED_LIBS is turned on so GDBRemoteCommunicationServer is trying to resolve llvm::Triple at link time and can't.
(In reply to comment #6) > Created attachment 13403 [details] > change all lldb modules to compile as shared library when BUILD_SHARED_LIBS > is set. > > The problem seems to be that most of the lldb modules are still compiled as > static library even if BUILD_SHARED_LIBS is turned on so > GDBRemoteCommunicationServer is trying to resolve llvm::Triple at link time > and can't. This one fixes all the problems except lldb-mi which uses pthread symbols but not linking to it: tools/lldb/tools/lldb-mi/CMakeFiles/lldb-mi.dir/MIUtilThreadBaseStd.cpp.o: In function `thread<unsigned int (*&)(void *), void *&, void>': /home/abuild/rpmbuild/BUILD/llvm/stage1/bin/../include/c++/v1/thread:358: undefined reference to `pthread_create' tools/lldb/tools/lldb-mi/CMakeFiles/lldb-mi.dir/MIUtilThreadBaseStd.cpp.o: In function `std::__1::__thread_specific_ptr<std::__1::__thread_struct>::get() const': /home/abuild/rpmbuild/BUILD/llvm/stage1/bin/../include/c++/v1/thread:131: undefined reference to `pthread_getspecific' tools/lldb/tools/lldb-mi/CMakeFiles/lldb-mi.dir/MIUtilThreadBaseStd.cpp.o: In function `std::__1::__thread_specific_ptr<std::__1::__thread_struct>::reset(std::__1::__thread_struct*)': /home/abuild/rpmbuild/BUILD/llvm/stage1/bin/../include/c++/v1/thread:178: undefined reference to `pthread_setspecific' clang-3.6: error: linker command failed with exit code 1 (use -v to see invocation)
Created attachment 13409 [details] added pthread part I am not seeing the pthread issue but I added it to this patch as described earlier.
(In reply to comment #8) > Created attachment 13409 [details] > added pthread part > > I am not seeing the pthread issue but I added it to this patch as described > earlier. This fixes the problem for me on Linux x86-64.
Thanks for your help Andy. > This fixes the problem for me on Linux x86-64 Can I close this Ismail?
(In reply to comment #10) > Thanks for your help Andy. > > > This fixes the problem for me on Linux x86-64 > > Can I close this Ismail? I'm not Ismail, but I can confirm that the build is now working.
Works now.
Sorry reopening since Andy's patch is not committed yet.
The compilation now works but it seems to underlink: [~]> lldb lldb: symbol lookup error: /opt/clang/lib64/liblldbInterpreter.so: undefined symbol: PyExc_KeyboardInterrupt [~]> ldd -r /opt/clang/lib64/liblldb* | grep undefined | wc -l 9875
Created attachment 14743 [details] updated patch to enable build of llvm-3.6.2 with shared libs Ping? Is this about some agenda to prevent shared library builds? [pointless rant deleted] We carry patches in our distro to make llvm build (like, version 3.6.0) and it is really strange when things are changed so that the patches don't apply anymore, but the issues the patches used to fix are _still_ _present_. So, here is yet another iteration of the patch, modified from the last one to work with llvm-3.6.2.
(In reply to comment #15) > Created attachment 14743 [details] > updated patch to enable build of llvm-3.6.2 with shared libs > > Ping? > > Is this about some agenda to prevent shared library builds? > [pointless rant deleted] > > We carry patches in our distro to make llvm build (like, version 3.6.0) > and it is really strange when things are changed so that the patches > don't apply anymore, but the issues the patches used to fix are _still_ > _present_. > > So, here is yet another iteration of the patch, modified from the last > one to work with llvm-3.6.2. lldb 3.7 does support shared libraries. We can close this bug.