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 <chy...@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 <vi...@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 <gclay...@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 <vi...@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 <gclay...@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 <vhar...@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 <vhar...@google.com> >>> wrote: >>> > > Xcode 6.1.1 on OSX 10.9.5 >>> > > >>> > > >>> > > On Sat, May 9, 2015 at 5:12 PM, Vince Harron <vhar...@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 <ovya...@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 <rib...@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 <gclay...@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 <ovya...@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 | ovya...@google.com >>> > > > _______________________________________________ >>> > > > lldb-dev mailing list >>> > > > lldb-dev@cs.uiuc.edu >>> > > > http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev >>> > > >>> > > >>> > > _______________________________________________ >>> > > lldb-dev mailing list >>> > > lldb-dev@cs.uiuc.edu >>> > > http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev >>> > > >>> > > >>> > > >>> > > -- >>> > > Oleksiy Vyalov | Software Engineer | ovya...@google.com >>> > > >>> > > _______________________________________________ >>> > > lldb-dev mailing list >>> > > lldb-dev@cs.uiuc.edu >>> > > http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev >>> > > >>> > > >>> > > >>> > > >>> > > -- >>> > > >>> > > Vince Harron | Technical Lead Manager | >>> vhar...@google.com | 858-442-0868 >>> > > >>> > > >>> > > >>> > > >>> > > -- >>> > > >>> > > Vince Harron | Technical Lead Manager | >>> vhar...@google.com | 858-442-0868 >>> > > >>> > > >>> > > >>> > > >>> > > -- >>> > > >>> > > Vince Harron | Technical Lead Manager | >>> vhar...@google.com | 858-442-0868 >>> > > >>> > > _______________________________________________ >>> > > lldb-dev mailing list >>> > > lldb-dev@cs.uiuc.edu >>> > > http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev >>> > >>> > >>> > _______________________________________________ >>> > lldb-dev mailing list >>> > lldb-dev@cs.uiuc.edu >>> > http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev >>> > >>> >>> >> >
_______________________________________________ lldb-dev mailing list lldb-dev@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
