Skip to content


Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP


ld: library not found for -lPods #16

yas375 opened this Issue · 17 comments

7 participants


First of all: thanks for the great tool! I'm really exited about it! :)

Just found a problem with compiling/linking when using Cocoapods.


Project FooBar with two targets FooBar and FooBarTests. I'm using Cocoapods and have some pods specified exclusively for FooBarTests target. Here is a Podfile:

platform :ios

pod 'MTDates'

target :FooBarTests, :exclusive => true do
  pod 'Kiwi'

There is a scheme called FooBar. It was created by Xcode automatically and it supports Test action.


  1. Open FooBar.xcworkspace
  2. Do Clean ("Product" => "Clean" in Xcode)
  3. Run tests from command line with command: ../xctool/ -workspace FooBar.xcworkspace -scheme FooBar test


Tests run successfully.


      ✗ Link FooBar (14 ms)
Ld /Users/yas/Library/Developer/Xcode/DerivedData/FooBar-ajkeysuvkvwfhjgmubnbplcrxzfl/Build/Products/Debug-iphonesimulator/ normal i386
    cd /Users/yas/code/FooBar
    setenv PATH "/Applications/"
    /Applications/ -arch i386 -isysroot /Applications/ -L/Users/yas/Library/Developer/Xcode/DerivedData/FooBar-ajkeysuvkvwfhjgmubnbplcrxzfl/Build/Products/Debug-iphonesimulator -F/Users/yas/Library/Developer/Xcode/DerivedData/FooBar-ajkeysuvkvwfhjgmubnbplcrxzfl/Build/Products/Debug-iphonesimulator -filelist /Users/yas/Library/Developer/Xcode/DerivedData/FooBar-ajkeysuvkvwfhjgmubnbplcrxzfl/Build/Intermediates/ -Xlinker -objc_abi_version -Xlinker 2 -ObjC -fobjc-arc -fobjc-link-runtime -Xlinker -no_implicit_dylibs -mios-simulator-version-min=6.1 -framework UIKit -framework Foundation -framework CoreGraphics -lPods -o /Users/yas/Library/Developer/Xcode/DerivedData/FooBar-ajkeysuvkvwfhjgmubnbplcrxzfl/Build/Products/Debug-iphonesimulator/

ld: library not found for -lPods
clang: error: linker command failed with exit code 1 (use -v to see invocation)

See full log


Run tests from Xcode once. It will compile libPods and libPods-FooBarTests. After that you can run tests from command line.


Here is a screencast Before I run tests first time with xctool is was already run from Xcode (cmd+u) and the libs were compiled. Then I've did "Clean" and after that xctool fails :(

Here is a test project It's a git repo. So you can see the steps I did to create the project.

Any chance to get it fixed? Thanks in advance! =)
I would be happy to help more. Just let me know how! (I don't know hot to fix it :) )

/cc @alloy @krzysztofzablocki


Thanks for the repro case. I'll try and look at this today.


@fpotter Thank you :)


Okay - I see what's happening. xctool cannot reproduce the "Find Implicit Dependencies" behavior of Xcode, and so it fails to see that it should build Pods + Pod-FooBarTests.

The workaround is easy enough - you can disable find implicit dependencies and then add "Pod" and "Pod-FooBarTests" to the scheme at the top.

screen shot 2013-05-04 at 6 25 40 pm

Maybe we can figure out how to reproduce that same behavior - not sure. Thanks for the report, though - we should add some docs + helpful error messages in the code when we see find implicit dependencies.

@fpotter fpotter closed this

@fpotter thank you! It works :)


This isn't fixing the issue for me. Is there something I'm missing?
screen shot 2013-05-10 at 11 01 56 am

xctool output:

> xctool test
=== TEST ===

  xcodebuild build build
    BotKit / BotKit (Debug)
      ✓ Check dependencies (70 ms)

  xcodebuild build build
    BotKit / BotKit (Debug)
      ✓ Check dependencies (63 ms)

    BotKit / BotKitTests (Debug)
      ✓ Check dependencies (0 ms)
      ✗ Link BotKitTests (9 ms)
Ld /Users/gordon/Library/Developer/Xcode/DerivedData/BotKit-asnqeysrhbuzreejdhtwnxpuzgvt/Build/Products/Debug-iphonesimulator/BotKitTests.octest/BotKitTests normal i386
    cd /Users/gordon/Code/thoughtbot/BotKit
    setenv PATH "/Applications/"
    /Applications/ -arch i386 -bundle -isysroot /Applications/ -L/Users/gordon/Library/Developer/Xcode/DerivedData/BotKit-asnqeysrhbuzreejdhtwnxpuzgvt/Build/Products/Debug-iphonesimulator -F/Users/gordon/Library/Developer/Xcode/DerivedData/BotKit-asnqeysrhbuzreejdhtwnxpuzgvt/Build/Products/Debug-iphonesimulator -F/Applications/ -F/Applications/ -filelist /Users/gordon/Library/Developer/Xcode/DerivedData/BotKit-asnqeysrhbuzreejdhtwnxpuzgvt/Build/Intermediates/ -bundle_loader /Users/gordon/Library/Developer/Xcode/DerivedData/BotKit-asnqeysrhbuzreejdhtwnxpuzgvt/Build/Products/Debug-iphonesimulator/ -Xlinker -objc_abi_version -Xlinker 2 -ObjC -framework SenTestingKit -fobjc-arc -fobjc-link-runtime -Xlinker -no_implicit_dylibs -mios-simulator-version-min=6.0 -framework CoreGraphics -framework QuartzCore -framework SenTestingKit -framework UIKit -framework Foundation -framework CoreData -lPods-BotKitTests -framework Accelerate -o /Users/gordon/Library/Developer/Xcode/DerivedData/BotKit-asnqeysrhbuzreejdhtwnxpuzgvt/Build/Products/Debug-iphonesimulator/BotKitTests.octest/BotKitTests

ld: library not found for -lPods-BotKitTests
clang: error: linker command failed with exit code 1 (use -v to see invocation)

** TEST FAILED: 0 of 0 tests passed ** (1286 ms)

@gfontenot What worked well for me on the RestKit tests was to create a concrete shared scheme for the Tests target and then add the explicit dependencies to that scheme. Your BotKit target is linking fine, but your BotKitTests is failing -- add the dependencies there. You'll want to use a shared scheme so that when you pull the project or push it to CI xctool will run.


Ah! That did the trick. Thanks, @blakewatters.

@alloy alloy referenced this issue from a commit in AFNetworking/AFNetworking
@blakewatters blakewatters Copy the shared schemes in during a build so that we do not have to d…
…eal with modifications to the schemes showing up as changes locally
@henrikhodne henrikhodne referenced this issue in travis-ci/travis-build

Change the default script for Objective-C to xctool #109

2 of 2 tasks complete

Hmm I'm battling this one too. I think I've followed @blakewatters suggestion and creating a separate shared scheme just for the application tests, but I'm still getting the linker failure.


So it looks like I can get around my problem if I do "build test" in my script, instead of just test.


Yeah @kcharwood the workaround for the time being is to do a build test ahead of time. AFN and RestKit were updated late last week to include this step.

I will shoot a PR revising the CI docs in the xctool README to include this wisdom in a few mins


I'm driving myself absolutely batty right now...

I have a couple CI machines, and one works perfectly, while the others fail with this error. In addition, it works fine on my local command line.

I've verified every CI machine is running xctool 0.1.2, and every CI machine has Xcode 4.6.2. I can't think of anything else to check. Any ideas?


@kcharwood did you make your scheme shared and have committed it?


@kcharwood Also try turning off Parallelize Build if you have that enabled. It can make the build nondeterministic if you have dependencies between projects.


I think I was fighting a few different issues here.

On my local machine, I could build test the normal scheme and it worked fine. Trying to do that on my CI machine, it wouldn't work.

I finally checked out a fresh repo on my local machine, and it failed the same way, so I switched back to using a shared scheme just for the test.

It looks like that after I build from within Xcode once, build test works fine on the normal scheme (which obviously is not ideal for CI).

For now, I'll stick with the shared scheme, although that is not ideal.


@kcharwood Xcode creates schemes automatically. But xctool - doesn't. That's why you need to use shared schemes. I think it's ok.


Hi @fpotter , I have found this topic useful to solve same issue with Jenkins CI.
Workaround with shared schemes works good.
I am using clean build and then test for tests scheme. OK there.
But clean build-tests still fails. And run-tests fails even if to run if after clean build.

Should this be tracked as a separate issue?


I just had this issue and it wasn't related to implicit dependencies, as it looks like the latest xctool versions are supposed to handle implicit dependencies. It was because I ran xctool like -scheme MyScheme instead of -workspace MyWorkspace.xcworkspace -scheme MyScheme. Facepalm. I hope this saves someone else the hour I just wasted. It would be nice if xctool defaulted to the workspace in the current directory over the project in the current directory, no?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.