Building lldb on Mac command line

I’m trying to build lldb on my Mac with cmake, but I’m running into this error about 79% of the way through.

/Users/mikesart/data/src/llvm/llvm/tools/lldb/include/lldb/Utility/SharingPtr.h:201:10: error: no member named ‘unique_ptr’ in namespace ‘std’
std::unique_ptr hold(p);

The compile line below is where it’s error’ing out on. If I explicitly add “-I/usr/lib/c++/v1”, it works. That directory appears to have the only “memory” header file which has unique_ptr in it.

If anyone has any suggestions on what I’ve done wrong here, I’d really appreciate it. Thanks.
-Mike

new-host:Utility mikesart$ /usr/bin/c++ -D_DEBUG -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -fPIC -fvisibility-inlines-hidden -Wall -W -Wno-unused-parameter -Wwrite-strings -Wmissing-field-initializers -pedantic -Wno-long-long -Wcovered-switch-default -Wnon-virtual-dtor -std=c++0x -std=c++11 -fno-rtti -fPIC -g -I/Users/mikesart/data/src/llvm/build/tools/lldb/source/Utility -I/Users/mikesart/data/src/llvm/llvm/tools/lldb/source/Utility -I/Users/mikesart/data/src/llvm/llvm/tools/lldb/include -I/Users/mikesart/data/src/llvm/build/tools/lldb/include -I/Users/mikesart/data/src/llvm/build/include -I/Users/mikesart/data/src/llvm/llvm/include -I/usr/include/python2.7 -I/Users/mikesart/data/src/llvm/llvm/tools/lldb/…/clang/include -I/Users/mikesart/data/src/llvm/build/tools/lldb/…/clang/include -I/Users/mikesart/data/src/llvm/llvm/tools/lldb/source/. -fno-exceptions -F/System/Library/PrivateFrameworks -o CMakeFiles/lldbUtility.dir/ARM_DWARF_Registers.cpp.o -c /Users/mikesart/data/src/llvm/llvm/tools/lldb/source/Utility/ARM_DWARF_Registers.cpp

I did a “cmake -DCMAKE_BUILD_TYPE=Debug …/llvm” followed by “make CXXFLAGS=-std=c++0x”.

Various version info:

new-host:include mikesart$ /usr/bin/c++ --version
Apple LLVM version 4.2 (clang-425.0.28) (based on LLVM 3.2svn)
Target: x86_64-apple-darwin12.3.0
Thread model: posix

new-host:include mikesart$ uname -a
Darwin new-host.ftrdhcpuser.net 12.3.0 Darwin Kernel Version 12.3.0: Sun Jan 6 22:37:10 PST 2013; root:xnu-2050.22.13~1/RELEASE_X86_64 x86_64

new-host:include mikesart$ /usr/bin/c++ -Wp,-v -x c++ - -fsyntax-only
clang -cc1 version 4.2 based upon LLVM 3.2svn default target x86_64-apple-darwin12.3.0
ignoring nonexistent directory “/usr/include/c++/4.2.1/i686-apple-darwin10/x86_64”
ignoring nonexistent directory “/usr/include/c++/4.0.0”
ignoring nonexistent directory “/usr/include/c++/4.0.0/i686-apple-darwin8/”
ignoring nonexistent directory “/usr/include/c++/4.0.0/backward”
#include “…” search starts here:
#include <…> search starts here:
/usr/include/c++/4.2.1
/usr/include/c++/4.2.1/backward
/usr/local/include
/usr/bin/…/lib/clang/4.2/include
/usr/include
/System/Library/Frameworks (framework directory)
/Library/Frameworks (framework directory)
End of search list.

Output of launching /usr/bin/c++ with “-v”:

new-host:Utility mikesart$ /usr/bin/c++ -v -D_DEBUG -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -fPIC -fvisibility-inlines-hidden -Wall -W -Wno-unused-parameter -Wwrite-strings -Wmissing-field-initializers -pedantic -Wno-long-long -Wcovered-switch-default -Wnon-virtual-dtor -std=c++11 -fno-rtti -fPIC -g -I/Users/mikesart/data/src/llvm/build/tools/lldb/source/Utility -I/Users/mikesart/data/src/llvm/llvm/tools/lldb/source/Utility -I/Users/mikesart/data/src/llvm/llvm/tools/lldb/include -I/Users/mikesart/data/src/llvm/build/tools/lldb/include -I/Users/mikesart/data/src/llvm/build/include -I/Users/mikesart/data/src/llvm/llvm/include -I/usr/include/python2.7 -I/Users/mikesart/data/src/llvm/llvm/tools/lldb/…/clang/include -I/Users/mikesart/data/src/llvm/build/tools/lldb/…/clang/include -I/Users/mikesart/data/src/llvm/llvm/tools/lldb/source/. -fno-exceptions -F/System/Library/PrivateFrameworks -o CMakeFiles/lldbUtility.dir/ARM_DWARF_Registers.cpp.o -c /Users/mikesart/data/src/llvm/llvm/tools/lldb/source/Utility/ARM_DWARF_Registers.cpp
Apple LLVM version 4.2 (clang-425.0.28) (based on LLVM 3.2svn)
Target: x86_64-apple-darwin12.3.0
Thread model: posix
“/usr/bin/clang” -cc1 -triple x86_64-apple-macosx10.8.0 -emit-obj -mrelax-all -disable-free -disable-llvm-verifier -main-file-name ARM_DWARF_Registers.cpp -pic-level 2 -mdisable-fp-elim -masm-verbose -munwind-tables -target-cpu core2 -target-linker-version 136 -v -g -coverage-file /Users/mikesart/data/src/llvm/build/tools/lldb/source/Utility/CMakeFiles/lldbUtility.dir/ARM_DWARF_Registers.cpp.o -resource-dir /usr/bin/…/lib/clang/4.2 -D _DEBUG -D __STDC_CONSTANT_MACROS -D __STDC_FORMAT_MACROS -D __STDC_LIMIT_MACROS -I /Users/mikesart/data/src/llvm/build/tools/lldb/source/Utility -I /Users/mikesart/data/src/llvm/llvm/tools/lldb/source/Utility -I /Users/mikesart/data/src/llvm/llvm/tools/lldb/include -I /Users/mikesart/data/src/llvm/build/tools/lldb/include -I /Users/mikesart/data/src/llvm/build/include -I /Users/mikesart/data/src/llvm/llvm/include -I /usr/include/python2.7 -I /Users/mikesart/data/src/llvm/llvm/tools/lldb/…/clang/include -I /Users/mikesart/data/src/llvm/build/tools/lldb/…/clang/include -I /Users/mikesart/data/src/llvm/llvm/tools/lldb/source/. -F/System/Library/PrivateFrameworks -fmodule-cache-path /var/folders/47/q5s2b1yj5x99nszz64pm0t580000gn/T/clang-module-cache -Wall -W -Wno-unused-parameter -Wwrite-strings -Wmissing-field-initializers -Wno-long-long -Wcovered-switch-default -Wnon-virtual-dtor -pedantic -std=c++11 -fconst-strings -fdeprecated-macro -fdebug-compilation-dir /Users/mikesart/data/src/llvm/build/tools/lldb/source/Utility -ferror-limit 19 -fmessage-length 163 -fvisibility-inlines-hidden -stack-protector 1 -mstackrealign -fblocks -fno-rtti -fobjc-runtime=macosx-10.8.0 -fobjc-dispatch-method=mixed -fobjc-default-synthesize-properties -fdiagnostics-show-option -fcolor-diagnostics -o CMakeFiles/lldbUtility.dir/ARM_DWARF_Registers.cpp.o -x c++ /Users/mikesart/data/src/llvm/llvm/tools/lldb/source/Utility/ARM_DWARF_Registers.cpp
clang -cc1 version 4.2 based upon LLVM 3.2svn default target x86_64-apple-darwin12.3.0
ignoring nonexistent directory “/Users/mikesart/data/src/llvm/build/tools/lldb/include”
ignoring nonexistent directory “/usr/include/c++/4.2.1/i686-apple-darwin10/x86_64”
ignoring nonexistent directory “/usr/include/c++/4.0.0”
ignoring nonexistent directory “/usr/include/c++/4.0.0/i686-apple-darwin8/”
ignoring nonexistent directory “/usr/include/c++/4.0.0/backward”
#include “…” search starts here:
#include <…> search starts here:
/Users/mikesart/data/src/llvm/build/tools/lldb/source/Utility
/Users/mikesart/data/src/llvm/llvm/tools/lldb/source/Utility
/Users/mikesart/data/src/llvm/llvm/tools/lldb/include
/Users/mikesart/data/src/llvm/build/include
/Users/mikesart/data/src/llvm/llvm/include
/usr/include/python2.7
/Users/mikesart/data/src/llvm/llvm/tools/lldb/…/clang/include
/Users/mikesart/data/src/llvm/build/tools/lldb/…/clang/include
/Users/mikesart/data/src/llvm/llvm/tools/lldb/source/.
/System/Library/PrivateFrameworks (framework directory)
/usr/include/c++/4.2.1
/usr/include/c++/4.2.1/backward
/usr/local/include
/usr/bin/…/lib/clang/4.2/include
/usr/include
/System/Library/Frameworks (framework directory)
/Library/Frameworks (framework directory)
End of search list.
In file included from /Users/mikesart/data/src/llvm/llvm/tools/lldb/source/Utility/ARM_DWARF_Registers.cpp:10:
In file included from /Users/mikesart/data/src/llvm/llvm/tools/lldb/source/Utility/ARM_DWARF_Registers.h:13:
In file included from /Users/mikesart/data/src/llvm/llvm/tools/lldb/include/lldb/lldb-private.h:15:
In file included from /Users/mikesart/data/src/llvm/llvm/tools/lldb/include/lldb/lldb-public.h:13:
In file included from /Users/mikesart/data/src/llvm/llvm/tools/lldb/include/lldb/lldb-defines.h:13:
In file included from /Users/mikesart/data/src/llvm/llvm/tools/lldb/include/lldb/lldb-types.h:14:
In file included from /Users/mikesart/data/src/llvm/llvm/tools/lldb/include/lldb/lldb-forward.h:15:
/Users/mikesart/data/src/llvm/llvm/tools/lldb/include/lldb/Utility/SharingPtr.h:201:10: error: no member named ‘unique_ptr’ in namespace ‘std’

It sounds like a missing “–stdlib=libc++” (or “–std=c++11”) flag … probably a bug in the Cmake scripts.

That said, building with cmake on Mac is still maturing – I believe there’s still no support for building/signing debugserver – so just the ‘lldb’ frontend tool is built which is suitable for remote debugging.

If you want a full-featured lldb+debugserver on Mac, you still have to build with xcode (or xcodebuild from the cmdline) after following the code_signing.txt instructions.

Cheers,

Dan

It sounds like a missing “–stdlib=libc++” (or “–std=c++11”) flag …
probably a bug in the Cmake scripts.

In case this might help anyone else, this is the line that got things
building for me:

cmake -DCMAKE_BUILD_TYPE=Debug -DCMAKE_CXX_FLAGS="-std=c++0x
-stdlib=libc++" -C ../llvm/ -G Ninja

****

** That said, building with cmake on Mac is still maturing – I believe
there’s still no support for building/signing debugserver – so just the
‘lldb’ frontend tool is built which is suitable for remote debugging.

If you want a full-featured lldb+debugserver on Mac, you still have to
build with xcode (or xcodebuild from the cmdline) after following the
code_signing.txt instructions.

I am failing miserably getting it to build with xcode. It's telling me the
link command is failing with what looks like a ton of missing symbols, but
I'm not even sure where I'd start looking on getting that fixed. I've got
the command line build working though - so I think I should be ok assuming
the check-lldb stuff will work from there. Just want to make sure I'm not
breaking anything on the Mac with our Linux changes.

Thanks.

Apple LLVM version 4.2 (clang-425.0.28) (based on LLVM 3.2svn)

Target: x86_64-apple-darwin12.4.0

Thread model: posix

"/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ld"
-demangle -dynamic -dylib -dylib_compatibility_version 1
-dylib_current_version 300.99.0 -arch x86_64 -dylib_install_name
@rpath/LLDB.framework/LLDB -exported_symbols_list
resources/lldb-framework-exports -macosx_version_min 10.7.0 -single_module
-t -o
/Users/mikesart/Library/Developer/Xcode/DerivedData/lldb-gpexmjfzwrushtagkbqcpavtmrgo/Build/Products/Debug/LLDB.framework/Versions/A/LLDB
-L/Users/mikesart/Library/Developer/Xcode/DerivedData/lldb-gpexmjfzwrushtagkbqcpavtmrgo/Build/Products/Debug
-L/Users/mikesart/data/src/llvm/llvm/tools/lldb/llvm-build/Release+Asserts/x86_64
-filelist
/Users/mikesart/Library/Developer/Xcode/DerivedData/lldb-gpexmjfzwrushtagkbqcpavtmrgo/Build/Intermediates/lldb.build/Debug/LLDB.build/Objects-normal/x86_64/LLDB.LinkFileList
-framework Carbon -framework DebugSymbols -lpython -lllvmclang -framework
Foundation -lxml2
/Users/mikesart/Library/Developer/Xcode/DerivedData/lldb-gpexmjfzwrushtagkbqcpavtmrgo/Build/Products/Debug/liblldb-core.a
-framework CoreFoundation -lobjc -framework Security -lc++ -lSystem
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../lib/clang/4.2/lib/darwin/libclang_rt.osx.a
-F/Users/mikesart/Library/Developer/Xcode/DerivedData/lldb-gpexmjfzwrushtagkbqcpavtmrgo/Build/Products/Debug
-F/System/Library/PrivateFrameworks
...

  clang::driver::toolchains::Darwin::TranslateArgs(llvm::opt::DerivedArgList
const&, char const*) const in libllvmclang.a(libclangDriver-ToolChains.o)

ld: symbol(s) not found for architecture x86_64

...

clang: error: linker command failed with exit code 1 (use -v to see
invocation)

On Mac I would just build with:

cd lldb
xcodebuild -configuration Debug

This should work find with 4.6.2 or 4.6.3 as long as you followed the lldb/docs/code_signing.txt steps.

I believe I've done the code signing part correctly. I successfully built
debugserver in Xcode at least.

In any case, I delnoded the entire tree, redid the subversion sync for
llvm, tools/clang, tools/lldb, and the xcodebuild command above still fails
at the linking stage. I copied the entire console log here in case someone
can spot something I'm doing wrong...

https://docs.google.com/file/d/0B05iIR_mx6ApaW44REJQLXh4UmM/edit?usp=sharing

Thanks.
-Mike

Try nuking your lldb/llvm-build folder and build again.

mikesart@Michaels-MacBook-Pro:~/data/src$ cd llvm
mikesart@Michaels-MacBook-Pro:~/data/src/llvm$ ll
total 0
drwxr-xr-x 2 mikesart staff 68 Jun 17 13:49 .
drwxr-xr-x 6 mikesart staff 204 Jun 14 23:55 …
mikesart@Michaels-MacBook-Pro:~/data/src/llvm$ svn co http://llvm.org/svn/llvm-project/llvm/trunk llvm

And just to verify, I delnoded everything, sync’d with subversion again, and it worked. There has to be state stored somewhere else?

In any case, it’s all building now. Thanks Greg.

I've also had situations (on Mac OS X) that required me to nuke the
~/Library/Developer/Xcode/DerivedData/lldb-* directories -- I believe
Xcode keeps some build files in there tooŠ

Good luck,
Dan

If you edit your Xcode application preferences and set them like this:

If anyone has a problem with Xcode consistently crashing when you try to modify those settings, it will work if you don’t have a project open. At least that was the case on my machine.

I also ran into the “user interaction is not allowed” failure when building debugserver. Perhaps this is because I’m ssh’d to the box now? In any case, I google’d a bit, and came across this solution:

http://stackoverflow.com/questions/577750/running-xcodebuild-from-a-forked-terminal

Ran this: security unlock-keychain /Users/mikesart/Library/Keychains/login.keychain

And can now build. If that’s not ok, please let me know.

So what is the best way to run the build verification tests on the Mac from the command line? I’ve tried various -scheme “Run Testsuite” type things, but nothing seems to happen. Just run dotest.py from the test directory?

Thanks.
-Mike

cd lldb/test
caffeinate ./dotest.py --compiler `xcrun -find clang`

"caffeinate" will stop your machine from going to sleep while running the test suite if you leave it and the screen saver comes on. We use the default Xcode compile by specifying "--compiler `xcrun -find clang`".

Greg

Note, if you are ssh'ed into the machine you are trying to run the testsuite on on Mac OS X, you'll have to run it as root, otherwise you won't be able to launch processes in the debugger. There's a shaggy dog story relating to that which is about as worth listening to as all other shaggy dog stories.

You can use the -R option to relocate the test output files (normally these get written to the test directory) to keep root from leaving files in your source directory.

Jim