Build Error When Used With Cocoapods-enabled Workspaces

[Agent007]

Hi Stew. I got this error on my cocoapods-based workspace (https://github.com/Agent007/TryiOSTestRunnerWithCocoapods): 'ld: library not found for -lPods'

Below is the more detailed error log. I have tried copying "$(inherited) $(XCODE_TEST_LDFLAGS)" into cocoapod's auto-generated .xcconfig files, but that didn't help either.

Thanks for creating this tool to run unit tests on the command line for iOS 6!

=== BUILD NATIVE TARGET TryiOS6TestRunnerWithCocoapods OF PROJECT TryiOS6TestRunnerWithCocoapods WITH CONFIGURATION Debug === Check dependencies

Ld /tmp/xcodetest/TryiOS6TestRunnerWithCocoapods/TryiOS6TestRunnerWithCocoapods.app/TryiOS6TestRunnerWithCocoapods normal i386 cd /Users/jeffl/Downloads/TryiOS6TestRunnerWithCocoapods setenv IPHONEOS_DEPLOYMENT_TARGET 6.0 setenv PATH "/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/usr/bin:/Applications/Xcode.app/Contents/Developer/usr/bin:/Users/jeffl/.rvm/gems/ruby-1.9.3-p286@try_iOS6_test_runner_with_cocoapods/bin:/Users/jeffl/.rvm/gems/ruby-1.9.3-p286@global/bin:/Users/jeffl/.rvm/rubies/ruby-1.9.3-p286/bin:/Users/jeffl/.rvm/bin:/usr/local/bin:/usr/local/mysql/bin:/usr/bin:/bin:/usr/sbin:/sbin:/opt/X11/bin" /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang -arch i386 -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator6.0.sdk -L/tmp/xcodetest/TryiOS6TestRunnerWithCocoapods -L/Users/jeffl/Downloads/TryiOS6TestRunnerWithCocoapods/Pods/TestFlightSDK -F/tmp/xcodetest/TryiOS6TestRunnerWithCocoapods -filelist /Users/jeffl/Library/Developer/Xcode/DerivedData/TryiOS6TestRunnerWithCocoapods-gjgpzjbikuzxvrheazsytdlidkcl/Build/Intermediates/TryiOS6TestRunnerWithCocoapods.build/Debug-iphonesimulator/TryiOS6TestRunnerWithCocoapods.build/Objects-normal/i386/TryiOS6TestRunnerWithCocoapods.LinkFileList -Xlinker -objc_abi_version -Xlinker 2 -ObjC -lTestFlight -lsqlite3.0 -lz -framework CFNetwork -framework CoreGraphics -framework CoreLocation -framework CoreTelephony -framework Foundation -framework MobileCoreServices -framework QuartzCore -framework Security -framework StoreKit -framework SystemConfiguration -framework UIKit -fobjc-arc -fobjc-link-runtime -Xlinker -no_implicit_dylibs -mios-simulator-version-min=6.0 -framework MessageUI -framework AudioToolbox -framework MapKit -framework UIKit -framework Foundation -framework CoreGraphics -lPods -o /tmp/xcodetest/TryiOS6TestRunnerWithCocoapods/TryiOS6TestRunnerWithCocoapods.app/TryiOS6TestRunnerWithCocoapods ld: library not found for -lPods clang: error: linker command failed with exit code 1 (use -v to see invocation)

[sgleadow]

Just had a look at this. It seems xcodebuild doesn't pick up the implicit workspace dependencies when running from the command line. If you load the workspace in the Xcode GUI, it magically resolves the fact that it needs to build the Pods project.

A few solutions I can think of:

1) Set up explicit dependencies. I've never had much luck with the implicit dependencies within a workspace actually working reliably, especially on build servers, so I have no trust in them now. Given Cocoapods handles most of the dependencies for you, you'd only need one explicit dependency between your main app and the Pods target (this was easy before Xcode 4.5, but I'm having trouble setting up explicit cross-project dependencies since I upgraded to 4.5)

2) Add a workspace option to the calls to xcodebuild, then it seems to resolve the dependency for you. Find the call to 'xcodebuild' in the script and add the option '-workspace TryiOS6TestRunnerWithCocoapods.xcworkspace'

I ended up doing (2). I also had to do a couple of other things do get the tests running in your sample project:

• Create a separate scheme to compile the unit test target, that has the same name as the unit test target. This is only due to shortcoming in the scripts and the way it sets up variables to build, load and run the tests... it assumes the same name. (the scheme also needs to be set to compile the tests for the "Run" action, as this is what gets invokes from xcodebuild). You could probably get around this by making the script smarter as well, but I took the easy option. I shared the schemes from my fork, so you'll see them.
• I had to re-enable linking in SenTestingKit through the build options. I assume you removed this because of issues with -all_load -ObjC... so I left these off.

Hopefully all of this makes sense in my fork, and pull request at https://github.com/Agent007/TryiOSTestRunnerWithCocoapods/pull/1

Let me know how you go.

[Agent007]

Thanks, Stew. It ran the first time I tried. But, it thinks the unit tests pass (when there is obviously a STFail in a test). And, subsequent runs hung mid-test despite deleting the app from the simulator and selecting "reset contents & settings" from the simulator's menu.

[Agent007]

By the way, here was the output when it was able to run the 1st time:

Launching '/tmp/xcodetest/TryiOS6TestRunnerWithCocoapods/TryiOS6TestRunnerWithCocoapods.app' on'Simulator - iOS 6.0' dyld: Library not loaded: @rpath/SenTestingKit.framework/Versions/A/SenTestingKit Referenced from: /Users/jeffl/Library/Application Support/iPhone Simulator/6.0/Applications/2AC7D8F0-F518-48CA-B1FB-B852F118AA5C/TryiOS6TestRunnerWithCocoapods.app/TryiOS6TestRunnerWithCocoapods Reason: image not found

[sgleadow]

I've seen that kind of issue when upgrading from 4.2 to 4.3 onwards, because the paths to all the framework locations changed. I think in 4.5 they changed some of the framework locations internally as well, at least the private ones.

[Agent007]

Ok. I am indeed running 4.5. Where should I configure the settings to the framework's new filepaths?

[sgleadow]

If you upgraded from a previous version of Xcode, maybe ensure xcode-select --print-path is pointing to the right place? There was a similar issue with Frank, that uses ios-sim to launch the app but very similar to waxsim discussed here https://groups.google.com/forum/#!topic/frank-discuss/oTKVLExfAG0

Also, was this possibly an issue with waxsim if compiled from the main waxsim repo? Jonathan Penn's fork fixed an issue that manifested itself like this from memory.

[Agent007]

xcode-select outputs "/Applications/Xcode.app/Contents/Developer" for me. I removed the old version of XCode a while ago. And, yes, I have been using Jonathan Penn's fork as your instructions indicated.