OCUnit tests to existing iOS project. "ld: file not found"

Question

I've been following this blog post: Adding unit tests to existing project.

I'm getting this error however:

ld: file not found: Build/Products/Debug-iphoneos/MyApp.app/MyApp Command /Developer/Platforms/iPhoneSimulator.platform/Developer/usr/bin/clang failed with exit code 1

I have my test target properties,

Bundle Loader = $(BUILT_PRODUCTS_DIR)/MyApp.app/MyApp

Test Host = $(BUNDLE_LOADER)

(which both equate to: build/Debug-iphoneos/MyApp.app/MyApp)

My wild guess is that those variables aren't pointing to the same location as the compiler. "build/Debug-iphoneos/..." vs "Build/Products/Debug-iphoneos/..."

I could be totally wrong on that guess, but either way, does anyone know what's causing this error or how I would fix those environment variables?

Thanks for any help,

Sam

Wallaroo

Maybe you have a case sensitive file system and have the wrong case on a letter? I've seen that one before. – Nodababus

Answer 1

Dig into ~/Library/Developer/Xcode/DerivedData, down into your project. From there, follow the Bundle Loader path. See what's actually there.

Now look at your Info.plist (or your target's Info settings) and look for "Executable file" or CFBundleExecutable. If it's ${EXECUTABLE_NAME}, check your target's "Product name" setting.

Keeler

Another thing to check is the Bundle Loader settings for your unit test target. That had the path to the app executable mostly hardcoded from when the Xcode 4 project was created. (I had since changed the product name in the app target and the unit test target had no idea about it.) – Anjanette

I had the same problem and this solved. The problem is that I had renamed the main target, and then Xcode got lost. – Chiasma

Cleaning or deleting derived data did nothing. I re-named my targets Product Name to what it should have been and its working. thanks! – Polymer

Answer 2

I ran into the same problem - it didn't make sense as the path it was using to the executable actually existed. Taking a close look at the compile command revealed that there was an extra space on the loader path that was the problem.

Erbil

Thanks! Finding this has just saved me some time. Was driving me nuts -- the was getting a file not found repeatedly on a bundle loader that clearly did exist. In the build settings editor, $(BUILT_PRODUCTS_DIR)/FSMTest.app/FSMTest is not the same as ` $(BUILT_PRODUCTS_DIR)/FSMTest.app/FSMTest` (ie. with a prepended space). Could Apple not have designed the settings editor dialogue with a modicum of checking? – Enkindle

On a similar note, don't put double quotes around this either, even if you have spaces in your app's name. – Kinsella

To be clear, don't put any quotes around this. Neither double nor single quotes worked for me, but no quotes DID work. – Lamination

I had a newline from a copy paste. Yikes! This was insanely helpful though, so thanks! – Sounding

Answer 3

Looking for "Search Paths" inside Build Settings. Probably there are unexistent paths under "Framework Search Paths" or the others paths like Library Search Paths

Harijan

Answer 4

There is a possibility that you changed the name of the application after creating your project. So the name of your project and application are different. In the path, use your application name as it would appear on itunes store instead of your project name.

Spanos

Answer 5

I had the same problem earlier and I resolved this by checking the Build Settings -> Base SDK of my unit test target, and make sure it's correct based on your project type (OSX or iOS).

Leeland

Answer 6

In your podfile make sure that you have included your tests as a target

target 'YourAppNameTests' do use_frameworks! pod 'AFNetworking', '2.6.0' pod 'TYMProgressBarView' end

This will automatically add Link Binary with Libraries Framework

Honour