lldb is failing to start on OSX

Hello,

I’m facing some weird problems while trying to run lldb on OSX (10.9.5)
It was okay up until recently but now lldb is complaining about not found dependencies:

ovyalov-macpro2:Debug ovyalov$ ./lldb
dyld: Library not loaded: @rpath/LLDB.framework/LLDB
Referenced from: /Users/ovyalov/google/lldb/git/lldb/DerivedData/lldb/Build/Products/Debug/./lldb
Reason: image not found
Trace/BPT trap: 5

I’m running lldb binary from DerivedData/lldb/Build/Products/Debug directory. It started to fail for me yesterday and I’m wondering whether it’s XCode or MacOS SDK updates.
However, if I set “Linking/Runpath search paths” option as …/DerivedData/lldb/Build/Products/Debug then lldb is running without issues.

Please advise what might be wrong here.
Thank you in advance.

As long as you don't build the BuildAndIntegration build you should be good. Build the "Debug" or "Release" configurations and you should be good.

To find out where the "lldb" binary will search for its @rpath binaries you can type:

% otool -lv lldb | grep -A2 LC_RPATH
          cmd LC_RPATH
      cmdsize 32
         path @loader_path (offset 12)

We see the path for a "Debug" configuration is to look in the current directory (@loader_path). If you look at the installed lldb:

% otool -lv `xcrun -find lldb` | grep -A2 LC_RPATH | grep path
         path @loader_path/../../Library/PrivateFrameworks (offset 12)
         path @loader_path/../../../SharedFrameworks (offset 12)
         path @loader_path/../../System/Library/PrivateFrameworks (offset 12)
         path @loader_path/../../Library/PrivateFrameworks (offset 12)

You can see it will look relative to the lldb binary (@loader_path) in a variety of different directories. This is how the BuildAndIntegration version is setup because you would install LLDB in a "bin" folder somewhere (like "/Applications/Xcode.app/Contents/Developer/usr/bin") and it will look for LLDB.framework and any other @rpath binaries using the paths mentioned in the LC_RPATH load commands of the executable.

Greg

Did you ever figure this out? I’m getting the same thing after updating my lldb sources and rebuilding:

$ /Users/ribrdb/Documents/git/lldb/DerivedData/lldb/Build/Products/Debug/lldb
dyld: Library not loaded: @rpath/LLDB.framework/LLDB
Referenced from: /Users/ribrdb/Documents/git/lldb/DerivedData/lldb/Build/Products/Debug/lldb
Reason: image not found
Trace/BPT trap: 5
$ otool -lv /Users/ribrdb/Documents/git/lldb/DerivedData/lldb/Build/Products/Debug/lldb|grep -A2 LC_RPATH
cmd LC_RPATH
cmdsize 32
path @loader_path (offset 12)
$ file /Users/ribrdb/Documents/git/lldb/DerivedData/lldb/Build/Products/Debug/LLDB.framework/LLDB

/Users/ribrdb/Documents/git/lldb/DerivedData/lldb/Build/Products/Debug/LLDB.framework/LLDB: Mach-O 64-bit dynamically linked shared library x86_64

It happens to me from time to time but I don’t know exactly why - as a workaround, set DYLD_FRAMEWORK_PATH to your output build directory, e.g. export DYLD_FRAMEWORK_PATH=/Users/ovyalov/google/lldb/git/lldb/DerivedData/lldb/Build/Products/Debug

Hi Greg,

This is still a problem for me. I just did a clean checkout and build. I’m unable to run lldb. This makes it very difficult to test my changes on OSX. =)

REPRO STEPS:

vharron-macpro3:ll vharron$ mkdir fresh
vharron-macpro3:ll vharron$ cd fresh
vharron-macpro3:fresh vharron$ git clone http://llvm.org/git/lldb.git
Cloning into ‘lldb’…
remote: Counting objects: 120337, done.
remote: Compressing objects: 100% (36468/36468), done.
remote: Total 120337 (delta 92692), reused 107965 (delta 82116)
Receiving objects: 100% (120337/120337), 30.90 MiB | 6.67 MiB/s, done.
Resolving deltas: 100% (92692/92692), done.
Checking connectivity… done.
vharron-macpro3:fresh vharron$ git clone http://llvm.org/git/lldb.git

Open ~/ll/fresh/lldb/lldb.xcworkspace
Select lldb-tool
Select Build
(wait for build to complete successfully)

vharron-macpro3:Debug vharron$ pwd

/Users/vharron/ll/fresh/lldb/DerivedData/lldb/Build/Products/Debug
vharron-macpro3:Debug vharron$ history|less

vharron-macpro3:Debug vharron$ otool -lv lldb | grep -A2 LC_RPATH
cmd LC_RPATH
cmdsize 32
path @loader_path (offset 12)
vharron-macpro3:Debug vharron$ ./lldb
dyld: Library not loaded: @rpath/LLDB.framework/LLDB
Referenced from: /Users/vharron/ll/fresh/lldb/DerivedData/lldb/Build/Products/Debug/./lldb
Reason: image not found
Trace/BPT trap: 5
vharron-macpro3:Debug vharron$ echo $DYLD_FRAMEWORK_PATH
/Users/vharron/ll/fresh/lldb/DerivedData/lldb/Build/Products/Debug
vharron-macpro3:Debug vharron$ ls -l LLDB.framework/LLDB
lrwxr-xr-x 1 vharron eng 21 May 8 22:04 LLDB.framework/LLDB → Versions/Current/LLDB
vharron-macpro3:Debug vharron$ ls -l LLDB.framework/Versions/Current/LLDB
-rwxr-xr-x 1 vharron eng 72990060 May 8 22:04 LLDB.framework/Versions/Current/LLDB
vharron-macpro3:Debug vharron$ ls -l
total 873336
drwxr-xr-x 6 vharron eng 204 May 9 15:55 LLDB.framework
-rw-r–r-- 1 vharron eng 2806473 May 8 22:04 LLDBWrapPython.cpp
-rwxr-xr-x 1 vharron eng 43807600 May 8 22:04 argdumper
-rwxr-xr-x 1 vharron eng 49332 May 8 22:04 darwin-debug
-rwxr-xr-x 1 vharron eng 5595984 May 9 15:55 debugserver
-rw-r–r-- 1 vharron eng 353044136 May 8 22:04 liblldb-core.a
-rwxr-xr-x 1 vharron eng 147776 May 9 15:55 lldb
-rwxr-xr-x 1 vharron eng 41134240 May 9 15:55 lldb-server
-rw-r–r-- 1 vharron eng 538509 May 8 22:04 lldb.py
vharron-macpro3:Debug vharron$

Xcode 6.1.1 on OSX 10.9.5

I forgot to “export” DYLD_FRAMEWORK_PATH blush

But still, this should be fixed in the documentation or in the build. Which should it be?

One step repro:

#!/bin/bash -ex

ROOT_DIR=$HOME/ll/fresh
LLDB_CONFIG=Debug
LLDB_BIN=$ROOT_DIR/lldb/DerivedData/lldb/Build/Products/$LLDB_CONFIG

mkdir -p $ROOT_DIR
cd $ROOT_DIR
git clone http://llvm.org/git/lldb.git &
git clone http://llvm.org/git/llvm.git &
git clone http://llvm.org/git/clang.git &
wait

mv clang llvm/tools/clang
mv llvm lldb

XCBUILD=“xcodebuild -scheme lldb-tool -workspace $ROOT_DIR/lldb/lldb.xcworkspace -configuration $LLDB_CONFIG build”

first clean build always fails but second one will succeed!

$XCBUILD || $XCBUILD

unset DYLD_FRAMEWORK_PATH

launch it

$LLDB_BIN/lldb

All you need to do to build LLDB with Xcode is:

% git clone http://llvm.org/git/lldb.git
% cd lldb
% xcodebuild -configuration Debug -target desktop

The Xcode build will checkout llvm and clang for you in the right spot and with the right llvm/clang repository versions. Some repos are locked down to certain versions of llvm and clang and it is best to let the build scripts do everything for you.

You don't need to set any DYLD_FRAMEWORK_PATH or anything. The "Debug" and "Release" configurations will build the "lldb" command line tool with an rpath that looks in the same directory as the "lldb" command line tool itself:

% cd build/Debug
% otool -lv lldb | grep -A3 LC_RPATH
          cmd LC_RPATH
      cmdsize 32
         path @loader_path (offset 12)

The "lldb" tool states it needs LLDB that is relative to the path:

% otool -lv lldb | grep -A5 LC_LOAD_DYLIB
...
          cmd LC_LOAD_DYLIB
      cmdsize 56
         name @rpath/LLDB.framework/LLDB (offset 24)
   time stamp 2 Wed Dec 31 16:00:02 1969
      current version 340.99.0
compatibility version 1.0.0

So it should load the LLDB framework from the current directory that the "lldb" tool is built in. This means you can't move the "lldb" tool to /usr/bin and move the "LLDB.framework" to /System/Library/Frameworks because the rpath isn't set correctly for that. If you look at the Xcode version of lldb we see if it setup differently:

% otool -lv `xcrun -find lldb` | grep -A3 LC_RPATH
          cmd LC_RPATH
      cmdsize 64
         path @loader_path/../../Library/PrivateFrameworks (offset 12)
Load command 18
          cmd LC_RPATH
      cmdsize 56
         path @loader_path/../../../SharedFrameworks (offset 12)
Load command 19
          cmd LC_RPATH
      cmdsize 64
         path @loader_path/../../System/Library/PrivateFrameworks (offset 12)
Load command 20
          cmd LC_RPATH
      cmdsize 64
         path @loader_path/../../Library/PrivateFrameworks (offset 12)
Load command 21

@loader_path is the current directory that contains the "lldb" executable.

Greg

BTW, I did an in-place upgrade on my laptop from OSX 10.9.5 to 10.10.3 and this problem disappeared (same exact binaries.)