Dear All, according to the web page, building with XCode 3.x is supported, but trying so result in build failures, both when using xcodebuild as well as when following the (FreeBSD) "make" instructions.
So my question is: Is building LLDB on Mac OSX Snow Leopard (still) supported? If yes, how can I fix the build failures, preferably the make based ones in the second part of this mail? First, trying XCode as suggested on http://lldb.llvm.org/build.html, failed as follows: ---------------------------------------- The links for Xcode builds point to non-existing / wrong pages, but that let aside, a simple SVN checkout > "svn co http://llvm.org/svn/llvm-project/lldb/trunk lldb" and then running > "cd lldb && xcodebuild -project lldb.xcodeproj -target lldb-tool" tries a "BuildAndIntegration" build, picking "/Developer/usr/bin/clang" as compiler (correct for XCode 3.x on Snow Leopard) but complains "clang: error: unable to execute command: clang-cc is not executable" Instead of stopping, it proceeds to checkout llvm and starts compiling that which generates tons of errors, first few cited here (paths shortened): > missing archive: '/.../lldb/build/llvm/x86_64/Release/lib/libclang.a' > missing archive: '/.../lldb/build/llvm/x86_64/Release/lib/libclangAnalysis.a' > missing archive: '/.../lldb/build/llvm/x86_64/Release/lib/libclangAST.a' several more of that follow, then (paths shortened) > % cd '/.../lldb/build/llvm/x86_64' && make -j2 clang-only VERBOSE=1 NO_RUNTIME_LIBS=1 PROJECT_NAME='llvm' > make: *** No rule to make target `clang-only'. Stop. > error: making llvm and clang child exited with value 2 it should stop here, but instead goes on (paths shortened): > CompileC > build/lldb.build/BuildAndIntegration/lldb-core.build/Objects-normal/x86_64/DynamicLibrary.o > source/Host/common/DynamicLibrary.cpp normal x86_64 c++ > com.apple.compilers.llvmgcc42 > cd /.../lldb > setenv LANG en_US.US-ASCII > /Developer/usr/bin/llvm-gcc-4.2 -x c++ -arch x86_64 > -fmessage-length=0 -pipe -Wno-trigraphs -fpascal-strings -fasm-blocks > -Os -Wmissing-field-initializers -Wreturn-type -Wnon-virtual-dtor > -Woverloaded-virtual -Wmissing-braces -Wparentheses -Wunused-label > -Wunused-variable -Wunused-value -Wuninitialized -Wnewline-eof > -D__STDC_CONSTANT_MACROS -D__STDC_LIMIT_MACROS > -DLLDB_CONFIGURATION_BUILD_AND_INTEGRATION -gdwarf-2 -iquote > /.../lldb/build/lldb.build/BuildAndIntegration/lldb-core.build/liblldb-core-generated-files.hmap > - > -I/.../lldb/build/lldb.build/BuildAndIntegration/lldb-core.build/liblldb-core-own-target-headers.hmap > - > -I/.../lldb/build/lldb.build/BuildAndIntegration/lldb-core.build/liblldb-core-all-target-headers.hmap > -iquote > /.../lldb/build/lldb.build/BuildAndIntegration/lldb-core.build/liblldb-core-project-headers.hmap > -Wreorder -F/.../lldb/build/BuildAndIntegration > -F/System/Library/PrivateFrameworks -iquote/.../lldb/include > -iquote/.../lldb/source -iquote/.../lldb/llvm/include > -iquote/.../lldb/llvm/tools/clang/include > -iquote/.../lldb/build/llvm/x86_64/include > -iquote/.../lldb/build/llvm/x86_64/tools/clang/include > -I/.../lldb/build/BuildAndIntegration/include -I/usr/include/libxml2 > - > -I/.../lldb/build/lldb.build/BuildAndIntegration/lldb-core.build/DerivedSources/x86_64 > - > -I/.../lldb/build/lldb.build/BuildAndIntegration/lldb-core.build/DerivedSources > - > -I/System/Library/Frameworks/Python.framework/Versions/2.7/include/python2.7 > -fno-rtti -Wglobal-constructors -flimit-debug-info -Wparentheses > -DLLDB_USE_BUILTIN_DEMANGLER -c > /.../lldb/source/Host/common/DynamicLibrary.cpp -o > /.../lldb/build/lldb.build/BuildAndIntegration/lldb-core.build/Objects-normal/x86_64/DynamicLibrary.o > > In file included from /.../lldb/source/Host/common/DynamicLibrary.cpp:10: > /.../lldb/include/lldb/Core/Error.h:14:36: error: > llvm/Support/DataTypes.h: No such file or directory Which is not really surprising, given that it failed to build a newer llvm & clang before. Second try, autoconf & make build: ---------------------------------------- Following the instruction for FreeBSD leads significantly further, successfully building llvm and clang. However it dies in the MacOSX specific parts of LLDB: Build environment: Snow Leopard 10.6.8 with XCode 3.2.6 and latest MacPorts of today installed. libcxx, libcxxabi, gcc / g++ 4.8 installed by MacPorts and up to date. llvm-3.5, clang-3.5 from SVN Attempted build: Following the instructions on the web page, I did: - a svn checkout of llvm trunk into ${myllvm} - a svn checkout of clang into ${myllvm}/tools/clang - a svn checkout of lldb into ${myllvm}/tools/lldb - created build directory at ${llvm}/../myBuild as ${mybuild} - cd ${mybuild} - configured as ${myllvm}/configure --enable-cxx11 --enable-optimized CC=/opt/local/bin/gcc CXX=/opt/local/bin/g++ This picks up gcc-4.8 - make CC=/opt/local/bin/gcc CXX=/opt/local/bin/g++ This sequence built llvm and clang. The LLDB build failed in file "source/Host/common/FileSpec.cpp" due to missing definition of "PATH_MAX". I had to: - adding "#include <limits.h>" at the top of the file to let the build proceed. The LLDB build finally failed in file "source/Host/macosx/Host.mm", because g++-4.8 can not compile the closures in function StartMonitoringChildProcess(). In fact, it already does not see the block variant of "::dispatch_source_set_cancel_handler", it only sees the function variant ::dispatch_source_set_cancel_handler_f, and complains about an undeclared symbol. If I comment out the offending lines (thereby breaking LLDB), then the build completes until final linker step of "liblldb.dylib". Linking fails with missing "-ledit" for libedit and "-lpanel" for the pannels extension to ncurses. Adding the missing linker options, then link fails with pthread_chdir() and pthread_fchdir() undefined. These interfaces do not exists on Snow Leopard, there seems to be no library that exports this functions. Using clang: Compiling with clang-3.5 fails because it can't parse the c++ stdlib header due to missing support for the "atomic" header. (Message: ".../include/lldb/Utility/SharingPtr.h:22:10: fatal error: 'atomic' file not found" Trying the llvm_3.4 release instead of trunk: Compiling with gcc-4.8 has the same problems as the SVN trunk version, except different symbol missing when linking liblldb.dylib: -ledit and -lpanel are apparently unneeded, but instead of it misses SystemRuntimeMacOSX::Initialize() and SystemRuntimeMacOSX::Terminate() Questions: Would it be possible to implement the handling of child process in standard C/C++ instead of Objective-C++ so g++-4.8 can compile it (or at least using the function interface instead of the blocks interface)? Shouldn't clang be able to compile LLDB, i.e. support all needed interfaces including "atomic" -- or -- how can clang be taught to use an appropriate c++ stdlib which includes "atomic"? Why do I need to checkout *and* *compile* a separate llvm and clang tree to build LLDB, even when the system has an installed llvm and clang? Any hints are most appreciated Björn -- | Bjoern Kahl +++ Siegburg +++ Germany | | "googlelogin@-my-domain-" +++ www.bjoern-kahl.de | | Languages: German, English, Ancient Latin (a bit :-)) |
signature.asc
Description: OpenPGP digital signature
_______________________________________________ lldb-dev mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
