[lldb-dev] lldb is failing to start on OSX

Vince Harron vince at nethacker.com
Tue May 19 18:23:22 PDT 2015


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.)



On Tue, May 19, 2015 at 10:13 AM, Ying Chen <chying at google.com> wrote:

> Hi Vince,
>
> OSX builder has vanilla image 10.9.5.
>
> Thanks,
> Ying
>
> On Mon, May 18, 2015 at 10:27 PM, Vince Harron <vince at nethacker.com>
> wrote:
>
>> Hi Ying,
>>
>> Is the OSX builder a Google image or a vanilla OSX image?
>>
>> Hi Greg,
>>
>> vharron-macbookpro:Debug vharron$ ls -lAF ./LLDB.framework/LLDB
>> lrwxr-xr-x  1 vharron  eng  21 May 16 09:28 ./LLDB.framework/LLDB@ ->
>> Versions/Current/LLDB
>> vharron-macbookpro:Debug vharron$ ls -lAF
>> ./LLDB.framework/Versions/Current/LLDB
>> -rwxr-xr-x  1 vharron  eng  73051980 May 18 21:06
>> ./LLDB.framework/Versions/Current/LLDB*
>> vharron-macbookpro:Debug vharron$ ./lldb
>> (lldb) quit
>> vharron-macbookpro:Debug vharron$ cd ..
>> vharron-macbookpro:build vharron$ Debug/lldb
>> (lldb) quit
>> vharron-macbookpro:build vharron$ echo $DYLD_FRAMEWORK_PATH
>> /Users/vharron/ll/tot/lldb/build/Debug
>> vharron-macbookpro:build vharron$ unset DYLD_FRAMEWORK_PATH
>> vharron-macbookpro:build vharron$ Debug/lldb
>> dyld: Library not loaded: @rpath/LLDB.framework/LLDB
>>   Referenced from: /Users/vharron/ll/tot/lldb/build/Debug/lldb
>>   Reason: image not found
>> Trace/BPT trap: 5
>>
>> I'm going to try to reproduce this on a VM with a vanilla OSX build
>> tomorrow.
>>
>>
>> On Tue, May 12, 2015 at 1:24 PM, Greg Clayton <gclayton at apple.com> wrote:
>>
>>> That should work. Can you verify that you have a "./LLDB.framework/LLDB"
>>> in the same directory as the "lldb" binary?
>>>
>>> This should be a symlink:
>>>
>>> % ls -lAF ./LLDB.framework/LLDB
>>> lrwxr-xr-x  1 gclayton  apple_sw  21 May  1 14:44 ./LLDB.framework/LLDB@
>>> -> Versions/Current/LLDB
>>> % ls -lAF ./LLDB.framework/Versions/Current/LLDB
>>> -rwxr-xr-x  1 gclayton  apple_sw  72865260 May  7 11:44
>>> ./LLDB.framework/Versions/Current/LLDB*
>>>
>>> Make sure the symlink is there and that it is correct?
>>>
>>> Greg
>>>
>>> > On May 12, 2015, at 12:13 PM, Vince Harron <vince at nethacker.com>
>>> wrote:
>>> >
>>> > Hi Greg,
>>> >
>>> > Thanks for your email.  Following those instructions exactly, I'm
>>> still getting the same error:
>>> > (10.9.5 XCode 6.2)
>>> >
>>> > git clone http://llvm.org/git/lldb.git
>>> > cd lldb
>>> > xcodebuild -configuration Debug -target desktop
>>> >
>>> > vharron-macpro3:fresh vharron$ lldb/build/Debug/lldb
>>> > dyld: Library not loaded: @rpath/LLDB.framework/LLDB
>>> >   Referenced from: /Users/vharron/ll/fresh/lldb/build/Debug/lldb
>>> >   Reason: image not found
>>> > Trace/BPT trap: 5
>>> >
>>> > vharron-macpro3:fresh vharron$ export
>>> DYLD_FRAMEWORK_PATH=/Users/vharron/ll/fresh/lldb/build/Debug
>>> > vharron-macpro3:fresh vharron$ lldb/build/Debug/lldb
>>> > (lldb) quit
>>> >
>>> > vharron-macpro3:Debug vharron$ otool -lv lldb | grep -A3 LC_RPATH
>>> >           cmd LC_RPATH
>>> >       cmdsize 32
>>> >          path @loader_path (offset 12)
>>> > Load command 18
>>> > vharron-macpro3:Debug vharron$ 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.
>>> >
>>> > That is my understanding but I haven't moved anything anywhere.  I'm
>>> trying to use them in the output location.
>>>
>>> >
>>> >
>>> >
>>> > On Tue, May 12, 2015 at 10:52 AM, Greg Clayton <gclayton at apple.com>
>>> wrote:
>>> > 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
>>> >
>>> >
>>> > > On May 9, 2015, at 11:44 PM, Vince Harron <vharron at google.com>
>>> wrote:
>>> > >
>>> > > 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
>>> > >
>>> > >
>>> > > On Sat, May 9, 2015 at 5:17 PM, Vince Harron <vharron at google.com>
>>> wrote:
>>> > > Xcode 6.1.1 on OSX 10.9.5
>>> > >
>>> > >
>>> > > On Sat, May 9, 2015 at 5:12 PM, Vince Harron <vharron at google.com>
>>> wrote:
>>> > > 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$
>>> > >
>>> > >
>>> > > On Wed, Feb 11, 2015 at 4:13 PM, Oleksiy Vyalov <ovyalov at google.com>
>>> wrote:
>>> > > 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
>>> > >
>>> > > On Wed, Feb 11, 2015 at 3:32 PM, Ryan Brown <ribrdb at google.com>
>>> wrote:
>>> > > 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
>>> > >
>>> > >
>>> > > On Mon Feb 02 2015 at 11:38:32 AM Greg Clayton <gclayton at apple.com>
>>> wrote:
>>> > > 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
>>> > >
>>> > >
>>> > > > On Feb 2, 2015, at 9:29 AM, Oleksiy Vyalov <ovyalov at google.com>
>>> wrote:
>>> > > >
>>> > > > 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.
>>> > > >
>>> > > >
>>> > > > --
>>> > > > Oleksiy Vyalov | Software Engineer | ovyalov at google.com
>>> > > > _______________________________________________
>>> > > > lldb-dev mailing list
>>> > > > lldb-dev at cs.uiuc.edu
>>> > > > http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
>>> > >
>>> > >
>>> > > _______________________________________________
>>> > > lldb-dev mailing list
>>> > > lldb-dev at cs.uiuc.edu
>>> > > http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
>>> > >
>>> > >
>>> > >
>>> > > --
>>> > > Oleksiy Vyalov | Software Engineer | ovyalov at google.com
>>> > >
>>> > > _______________________________________________
>>> > > lldb-dev mailing list
>>> > > lldb-dev at cs.uiuc.edu
>>> > > http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
>>> > >
>>> > >
>>> > >
>>> > >
>>> > > --
>>> > >
>>> > > Vince Harron |         Technical Lead Manager |
>>> vharron at google.com |    858-442-0868
>>> > >
>>> > >
>>> > >
>>> > >
>>> > > --
>>> > >
>>> > > Vince Harron |         Technical Lead Manager |
>>> vharron at google.com |    858-442-0868
>>> > >
>>> > >
>>> > >
>>> > >
>>> > > --
>>> > >
>>> > > Vince Harron |         Technical Lead Manager |
>>> vharron at google.com |    858-442-0868
>>> > >
>>> > > _______________________________________________
>>> > > lldb-dev mailing list
>>> > > lldb-dev at cs.uiuc.edu
>>> > > http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
>>> >
>>> >
>>> > _______________________________________________
>>> > lldb-dev mailing list
>>> > lldb-dev at cs.uiuc.edu
>>> > http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
>>> >
>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20150519/b02b3e75/attachment.html>


More information about the lldb-dev mailing list