> I'm not sure how it works on Windows -- cygwin can be finicky sometimes. On > Linux though, the following linker invocation works: >
My current fresh cygwin install seems surprising stable, all random crashes are gone! The only catch so far is the configure, specifically lldb Makefile. > > llvm[3]: Linking Debug+Asserts Shared Library liblldb.so > g++ -I/home/baldrick/lldb/build/include > -I/home/baldrick/lldb/build/tools/lldb/lib -I/home/baldrick/lldb/llvm/include > -I/home/baldrick/lldb/llvm/tools/lldb/lib -D_DEBUG -D_GNU_SOURCE > -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -g > -fvisibility-inlines-hidden -fno-exceptions -fno-rtti -fPIC > -Woverloaded-virtual -Wcast-qual -std=c++0x -g -Wl,-R -Wl,'$ORIGIN' > -L/home/baldrick/lldb/build/Debug+Asserts/lib > -L/home/baldrick/lldb/build/Debug+Asserts/lib -pedantic -Wno-long-long > -Wall -W -Wno-unused-parameter -Wwrite-strings -Wno-uninitialized -shared > -o /home/baldrick/lldb/build/Debug+Asserts/lib/liblldb.so \ > -Wl,--whole-archive -llldbAPI -llldbBreakpoint -llldbCommands > -llldbCore -llldbExpression -llldbHostCommon -llldbInitAndLog > -llldbInterpreter -llldbPluginABIMacOSX_arm -llldbPluginABIMacOSX_i386 > -llldbPluginABISysV_x86_64 -llldbPluginDisassemblerLLVM > -llldbPluginDynamicLoaderStatic -llldbPluginDynamicLoaderPOSIX > -llldbPluginEmulateInstructionARM > -llldbPluginLanguageRuntimeCPlusPlusItaniumABI > -llldbPluginLanguageRuntimeObjCAppleObjCRuntime > -llldbPluginObjectContainerBSDArchive -llldbPluginObjectFileELF > -llldbPluginObjectFilePECOFF -llldbPluginOperatingSystemPython > -llldbPluginPlatformGDBServer -llldbPluginProcessGDBRemote > -llldbPluginSymbolFileDWARF -llldbPluginSymbolFileSymtab > -llldbPluginUnwindAssemblyInstEmulation -llldbPluginUnwindAssemblyx86 > -llldbPluginUtility -llldbSymbol -llldbTarget -llldbUtility -lclangAnalysis > -lclangAST -lclangBasic -lclangCodeGen -lclangFrontend -lclangDriver > -lclangEdit -lclangLex -lclangParse -lclangSema -lclangSerialization > -lLLVMMCDisass! embler - llldbPluginPlatformMacOSX -llldbPluginPlatformLinux -llldbPluginPlatformFreeBSD -lclangRewriteCore -lclangRewriteFrontend -llldbHostLinux -llldbPluginProcessLinux -llldbPluginProcessPOSIX -llldbPluginDynamicLoaderMacOSX -llldbPluginDynamicLoaderDarwinKernel -llldbPluginOperatingSystemDarwinKernel -Wl,--no-whole-archive -lLLVMLinker -lLLVMArchive -lLLVMMCJIT -lLLVMJIT -lLLVMRuntimeDyld -lLLVMExecutionEngine -lLLVMipo -lLLVMVectorize -lLLVMInstrumentation -lLLVMBitWriter -lLLVMBitReader -lLLVMAsmParser -lLLVMHexagonCodeGen -lLLVMHexagonDesc -lLLVMHexagonInfo -lLLVMHexagonAsmPrinter -lLLVMNVPTXCodeGen -lLLVMNVPTXDesc -lLLVMNVPTXInfo -lLLVMNVPTXAsmPrinter -lLLVMMBlazeDisassembler -lLLVMMBlazeCodeGen -lLLVMMBlazeDesc -lLLVMMBlazeAsmPrinter -lLLVMMBlazeAsmParser -lLLVMMBlazeInfo -lLLVMCppBackendCodeGen -lLLVMCppBackendInfo -lLLVMMSP430CodeGen -lLLVMMSP430Desc -lLLVMMSP430Info -lLLVMMSP430AsmPrinter -lLLVMXCoreDisassembler -lLLVMXCoreCodeGen -lLLVMXCoreDesc -lLLVMXCoreInfo -lLLVMXC! oreAsmPri nter -lLLVMMipsDisassembler -lLLVMMipsCodeGen -lLLVMMipsAsmParser -lLLVMMipsDesc -lLLVMMipsInfo -lLLVMMipsAsmPrinter -lLLVMARMDisassembler -lLLVMARMCodeGen -lLLVMARMAsmParser -lLLVMARMDesc -lLLVMARMInfo -lLLVMARMAsmPrinter -lLLVMPowerPCCodeGen -lLLVMPowerPCDesc -lLLVMPowerPCInfo -lLLVMPowerPCAsmPrinter -lLLVMSparcCodeGen -lLLVMSparcDesc -lLLVMSparcInfo -lLLVMX86Disassembler -lLLVMX86AsmParser -lLLVMX86CodeGen -lLLVMSelectionDAG -lLLVMAsmPrinter -lLLVMMCParser -lLLVMCodeGen -lLLVMScalarOpts -lLLVMInstCombine -lLLVMTransformUtils -lLLVMipa -lLLVMAnalysis -lLLVMX86Desc -lLLVMX86Info -lLLVMTarget -lLLVMX86AsmPrinter -lLLVMMC -lLLVMObject -lLLVMX86Utils -lLLVMCore -lLLVMSupport -Wl,--no-undefined -L/usr/lib/python2.6/config -lpthread -ldl -lutil -lm -lpython2.6 -lrt -lpthread -lrt -ldl -lm Thank you! > > > Out of curiosity, what made you abandon the cmake route? I was hoping to take > the cmakefiles from the windows branch and port them to Linux at some > point... It's somewhat concerning if they are problematic even on Windows. Problematic - did I say that? I did not abandon cmake, but the current lldb seems to require MSVC2012 to do a native windows build and my dev environment is still pinned to MSVC2008. Since, I just happen to have a leftover llvm+clang 3.2 cygwin build, it seemed to be the easiest way to try the windows branch. Actually, I have a bunch of different 3.2 setups so out of habit I might try some other permutations too. There is another issue, I had problems compiling Interpreter/LLDBWrapPython.cpp. Two python callbacks did not have extern "C" linkage and I had to add that. I am not sure if this is lldb.swig and/or swig problem or some scryptology issue. My swig reports - SWIG Version 2.0.9 is this recent enough for a build? > > > Best of luck, > Dan > Cheers, Paweł > On 2013-01-16, at 5:23 PM, Pawel Wodnicki wrote: > >> Hi, >> >> I got to the point where I can link on cygwin. I am using >> configure/make to build, but at the moment it seems to be >> a bit broken and on cygwin does not produce proper link command. >> >> I just want to link for now :-) so I am fiddling with Makefile >> and running into link problems like: >> >> .../lib/liblldbExpression.a(DWARFExpression.o):DWARFExpression.cpp:(.text+0x1d74): >> undefined reference to`lldb_private::DataEncoder::~DataEncoder()' >> >> I do not think I have a complete nor even correct link order (pasted >> below for reference) and the moment I do not have access to OS X >> nor Linux machine to check. >> >> Is there a way to determine proper order of dependencies for lldb? >> >> Paweł >> >> >> >> -llldbAPI -llldbBreakpoint -llldbCommands \ >> -llldbCore -llldbExpression -llldbHostCommon -llldbInitAndLog \ >> -llldbInterpreter -llldbPluginABIMacOSX_arm -llldbPluginABIMacOSX_i386 \ >> -llldbPluginABISysV_x86_64 -llldbPluginDisassemblerLLVM \ >> -llldbPluginDynamicLoaderStatic -llldbPluginEmulateInstructionARM \ >> -llldbPluginLanguageRuntimeCPlusPlusItaniumABI \ >> -llldbPluginLanguageRuntimeObjCAppleObjCRuntime \ >> -llldbPluginObjectContainerBSDArchive -llldbPluginObjectFileELF \ >> -llldbPluginObjectFilePECOFF -llldbPluginPlatformGDBServer \ >> -llldbPluginProcessGDBRemote -llldbPluginSymbolFileDWARF \ >> -llldbPluginSymbolFileSymtab -llldbPluginUnwindAssemblyInstEmulation \ >> -llldbPluginUnwindAssemblyx86 -llldbPluginUtility -llldbSymbol \ >> -llldbTarget -llldbUtility -lclangAnalysis -lclangAST -lclangBasic \ >> -lclangCodeGen -lclangFrontend -lclangDriver -lclangEdit \ >> -lclangLex -lclangRewriteCore -lclangRewriteFrontend -lclangParse >> -lclangSema -lclangSerialization \ >> -lLLVMMCDisassembler -llldbPluginPlatformMacOSX \ >> -llldbPluginPlatformLinux -llldbPluginPlatformFreeBSD \ >> -llldbPluginDynamicLoaderPOSIX -Wl,--no-whole-archive \ >> -lLLVMLinker -lLLVMArchive -lLLVMMCJIT -lLLVMJIT -lLLVMRuntimeDyld \ >> -lLLVMExecutionEngine -lLLVMipo -lLLVMVectorize -lLLVMInstrumentation \ >> -lLLVMBitWriter -lLLVMBitReader -lLLVMAsmParser -lLLVMX86AsmParser \ >> -lLLVMX86Disassembler -lLLVMX86CodeGen -lLLVMSelectionDAG \ >> -lLLVMAsmPrinter -lLLVMMCParser -lLLVMCodeGen -lLLVMScalarOpts \ >> -lLLVMInstCombine -lLLVMTransformUtils -lLLVMipa -lLLVMAnalysis \ >> -lLLVMX86Desc -lLLVMX86Info -lLLVMTarget -lLLVMX86AsmPrinter -lLLVMMC \ >> -lLLVMObject -lLLVMX86Utils -lLLVMCore -lLLVMSupport -Wl,--no-undefined \ >> -lpthread -ldl -lm >> _______________________________________________ >> lldb-dev mailing list >> [email protected] >> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev > _______________________________________________ lldb-dev mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
