My case is simple, a workspace with two sibling projects: one main (iOS) app and a project that builds several static library targets used by the app.
Here's how I have configured the build:
After a clean (and deletion of the derived data), a build nets me this error during the build of the main project:
ld: library not found for -lChipmunk clang: error: linker command failed with exit code 1 (use -v to see invocation) Command /Developer/Platforms/iPhoneSimulator.platform/Developer/usr/bin/clang failed with exit code 1
Sure enough, if I look in the newly-created derived data, the only object files to be found are for the main app, not the libraries. A widespread 'find' for *.o files doesn't reveal anything relevant, so the libraries aren't getting lost, they're definitely not being built.
Some supplementary points:
I've just figured out a workaround, which is to add all the deps' targets into the 'build' part of the main app's scheme. I had tried this before without success, but hadn't realised that I could drag the targets around in the list to get the right build order. Builds now happen in the correct order, both after a clean, and after changes in either library or main app source.
I'm leaving the question here, because manually sorting out a build order surely shouldn't be necessary. There has to be something wrong with how I have things set up.
Launch Xcode, then click “Create a new Xcode project” in the Welcome to Xcode window or choose File > New > Project.
Workspaces Extend the Scope of Your Workflow Although a project can contain references to other projects, working on interrelated projects in Xcode 3 is complicated; most workflows are confined to a single project.
Editing the scheme (swapping around build targets, un-/check "Parallelize Build" and/or "Find Implicit Dependencies") didn't work for me. I still had to clean build the project, after any code change in the static lib. Searching the dev forums, I finally found this answer, which worked wonders.
Make sure the Identity and Type inspector is showing and select the libWhatever.a file in your application's project (not the library). If you see Location: Relative to Project [or Relative to Group], this is your problem.
- Click Relative to Project and change it to Relative to Build Products.
- This will change the type of the link, but it will still be broken.
- Click the locate button and find the output file.
Adding a static lib to an existing project via Build Phases -> Link Binary with Libraries automatically makes it "Relative to Group" (if both are siblings in the same workspace). Changing its location the way described above resolves the build dependency problem and in the project navigator your .a file should appear in black letters (instead of red).
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With