“File not found”, “linker command failed with exit

2019-01-21 19:18发布

问题:

Am developing an existing iOS application and I have to write unit test cases for this project. It is building and running in Simulator 6.0. Whenever I try to test the project, it is showing the error message below. Am not able to figure the exact error.

id: file not found: /Users/Yuva/Library/Developer/Xcode/DerivedData/FlyApp-aexukpgtbathuadgxlnm/Build/Products/Debug-iphonesimulator/FlyApp.app/FlyApp
clag: error: linker command failed with exit code 1 (use -v to see invocation)

Could you please help me to solve this linker error and test the app?

回答1:

This error driven me crazy for 1.30 hrs

I have changed my product name and disabled the snapshot option. Then suddenly this error pop out.

The error is ld: file not found:.././previousproductname.app/previousproductname

Steps I've followed to debug and fix

  1. Opened the organizer deleted the deriveddata, restart Xcode. - not resolved

  2. Followed the steps of this link http://twobitlabs.com/2011/06/adding-ocunit-to-an-existing-ios-project-with-xcode-4/ - same error, not resolved.

  3. Finally changed the Scheme name, deleted my old scheme and added new, have solved my issue.

All the above steps are valid.

Then



回答2:

I encountered the same error message. Turned out I had renamed my app target and had not updated the test target, Build Settings, Bundle Loader setting to my new app name.

More details on this setting can be found at Adding Unit Tests to an existing iOS project with Xcode 4 I reviewed the same steps and it helped me fix my project in Xcode 5.



回答3:

Delete your scheme then re-create it (click new icon or using autocreate of xcode). It works for me.



回答4:

You must have changed your product name. Due to mis-match of your workspace name and product(application)name this error occurs.

You just need to replace the workspace name to product(application) name in the TEST HOST Build settings of the ProjectName-Tests targe as stated in the image. To catch up that, select to ProjectName-Tests target, select Build Settings, search for the Test Host term.

This is the standard configuration solution for this error.

Cheers!!



回答5:

On xcode 6 you need to:

  1. go to products folder
  2. click on file .xctext
  3. on "TARGETS" choose Tests
  4. and on Host Application choose your application.
  5. Click build app.

Works for me!



回答6:

ARGH! This is a terribly frustrating issue that came out of the blue from my XCode 8.2

In my case it came down to removing my Tests target from the scheme, building and running the main app, then readding the Tests target to the 'Test' section.

It appears that the Tests target was trying to find something it wanted in the Derived Data which wasn't built yet. Running the app without trying to build tests too allowed the previously missing derived data to be prepared.

...Insanity is doing the same thing in XCode twice and expecting the same result :|



回答7:

Your linker is looking for a file at: /Users/Yuva/Library/Developer/Xcode/DerivedData/FlyApp-aexukpgtbathuadgxlnm/Build/Products/Debug-iphonesimulator/FlyApp.app/FlyApp

Did you follow the path to ascertain if the file is there? Note that FlyApp.app is probably a package and you'll have to "see package contents" if you're viewing from the Finder. If it's not there, either 1) you need to build FlyApp.app first, or 2) you have something in your test code that depends on it being there, which can't be determined from your question.



回答8:

The answer lies on your Build Settings > Library Search Paths entry. Make sure there are no fully qualified paths listed there. Decorate them with the $SRCROOT idiom and enclose the path with double quotes. If there are any escape backslashes make sure to remove them as well.

Do a Clean and then Build and you should be back in business. This seem to be an issue with Xcode 5.x



回答9:

Create a new scheme. The bundle id / target name / executable / project name etc. are all slightly different concepts. If you change one (as I did) the old scheme may still be set to look for the old value as the name of the executable, while the build process may have been updated to no longer build that executable.