[lldb-dev] LLDB @ Mac OSX: build on Snow Leopard (still) supported?

Tue Feb 4 09:47:21 PST 2014

 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 at -my-domain-"   +++   www.bjoern-kahl.de  |
| Languages: German, English, Ancient Latin (a bit :-)) |

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 356 bytes
Desc: OpenPGP digital signature
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20140204/c8c34101/attachment.sig>