Summary: When you embed frameworks within an application, you link them with a relative path such as @executable_path or @loader_path. That's how the framework code is found by the application's executable at runtime. However, Xcode does not respect these relative paths when debugging or running the app. If the embedded framework happens to be built in the same folder as the app, then Xcode will attempt to load the copy of the framework in the "build" folder rather than the copy of framework embedded within the app. This can cause major problems if the framework is also linked with relative paths, because the linked files won't be in the correct location relative to the framework. This causes headaches for us, because we have a suite of applications that use a number of embedded frameworks, helper apps, and helper tools. These are distributed in a hierarchical source code repository; sometimes we have multiple targets within the same Xcode project, sometimes in separate Xcode projects in different locations within the hierarchy. Thus, it is crucial to us that relative linked paths work correctly during the build process, during debugging, and at runtime. Steps to Reproduce: 1. Unzip the attached sample Xcode project DebugBug, and open "DebugBug.xcodeproj" in Xcode. 2. Set active build configuration to Debug, the active target to DebugBug, and build the target. 3. Switch to Finder, and delete "SecondFramework.framework" in the project's "build/Debug" folder. This simulates the second framework's being pre-built in a different location in the source repository, which is the situation for some of our apps. 4. Switch back to Xcode, set the active executable to DebugBug, and start the debugger. Expected Results: The executable successfully runs in the debugger. Actual Results: Program received signal: "SIGTRAP". dyld: Library not loaded: @loader_path/../Frameworks/SecondFramework.framework/Versions/A/SecondFramework Referenced from: DebugBug/build/Debug/FirstFramework.framework/Versions/A/FirstFramework Reason: image not found Regression: This bug occurs both in Xcode 3.0 (IDE/Core 921.0, ToolSupport 893.0) on Mac OS X 10.5.3 and in Xcode 2.5 (IDE 799.0, Core 798.0, ToolSupport 794.0) on Mac OS X 10.4.11. The bug does not occur if I run the app from Finder or debug the app using gdb from the command-line, so it is definitely an Xcode bug. Notes: Note that the "Referenced From:" is in the wrong location. When I debug "DebugBug/build/Debug/DebugBug.app/Contents/MacOS/DebugBug", it should be loading FirstFramework from "DebugBug/build/Debug/DebugBug.app/Contents/Frameworks/FirstFramework.framework/Versions/A/FirstFramework", not from "DebugBug/build/Debug/FirstFramework.framework/Versions/A/FirstFramework". The workaround for this bug is to delete "DebugBug/build/Debug/FirstFramework.framework". If I delete that before debugging or running, then the problem does not occur. Obviously, Xcode is looking within the "DebugBug/build" folder for the framework. This workaround is very inconvenient for us, though, because the same framework might be linked by a number of apps or other frameworks, so we have to be extremely careful about when we can delete it and when we can't. Moreover, we have to add custom build scripts to our apps to delete the framework just so that we can debug, which is really lame. Attached sample Xcode project as "DebugBug.zip". 15-Jun-2008 05:49 PM Jeff Johnson: Actually, the 'workaround' of deleting the framework from the build directory turns out to be worse than I first thought, because once the framework is deleted, all subsequent re-builds of the main app fail. Also, there are problems with Xcode finding/indexing headers in the embedded framework after it's deleted.