Skip to content

Build setting `SDKROOT` has multiple values #1462

luketheobscure opened this Issue Oct 9, 2013 · 18 comments


  • What did you do?

Just a basic "pod install". I even nuked my pods folder- still get that same error.

(anonymized username in stack trace)


   CocoaPods : 0.26.2
        Ruby : ruby 2.0.0p247 (2013-06-27 revision 41674) [x86_64-darwin12.4.0]
    RubyGems : 2.0.3
        Host : Mac OS X 10.8.5 (12F45)
       Xcode : 5.0 (5A1413)
Ruby lib dir : /Users/***/.rbenv/versions/2.0.0-p247/lib
Repositories : master - @ 71cfe884af3f1bdb439362dc332786251cb757b5


platform :ios, "6.0"
pod "AFNetworking", '~> 1.3'
pod 'UIDeviceAddition', '~> 1.0'
pod 'XMLDictionary', '~> 1.2.1'
pod 'DDPageControl', '~> 0.1.0'
pod 'CustomBadge', '~> 2.0'
pod 'MBProgressHUD', '~> 0.7'
pod 'SSToolkit', '~> 1.0.3'
pod 'FMDB', '~> 2.0'
pod 'JSONKit', :inhibit_warnings => true
pod 'KeenClient', '~> 3.2.1'
pod 'SDWebImage', '~> 3.2'
pod 'RestKit', '~> 0.21.0'
pod 'QuickDialog', '~> 0.9'
pod 'ViewDeck', '~> 2.2.11'


RuntimeError - Build setting `SDKROOT` has multiple values: `{"Release"=>"iphoneos", "Debug"=>"iphoneos", "Debug-Live"=>nil, "Debug-Beta"=>nil}`
/Users/***/.rbenv/versions/2.0.0-p247/lib/ruby/gems/2.0.0/gems/xcodeproj-0.13.0/lib/xcodeproj/project/object/native_target.rb:77:in `common_resolved_build_setting'
/Users/***/.rbenv/versions/2.0.0-p247/lib/ruby/gems/2.0.0/gems/xcodeproj-0.13.0/lib/xcodeproj/project/object/native_target.rb:84:in `sdk'
/Users/***/.rbenv/versions/2.0.0-p247/lib/ruby/gems/2.0.0/gems/xcodeproj-0.13.0/lib/xcodeproj/project/object/native_target.rb:90:in `platform_name'
/Users/***/.rbenv/versions/2.0.0-p247/lib/ruby/gems/2.0.0/gems/xcodeproj-0.13.0/lib/xcodeproj/project/object/native_target.rb:252:in `block in add_system_framework'
/Users/***/.rbenv/versions/2.0.0-p247/lib/ruby/gems/2.0.0/gems/xcodeproj-0.13.0/lib/xcodeproj/project/object/native_target.rb:250:in `each'
/Users/***/.rbenv/versions/2.0.0-p247/lib/ruby/gems/2.0.0/gems/xcodeproj-0.13.0/lib/xcodeproj/project/object/native_target.rb:250:in `add_system_framework'
/Users/***/.rbenv/versions/2.0.0-p247/lib/ruby/gems/2.0.0/gems/xcodeproj-0.13.0/lib/xcodeproj/project/project_helper.rb:58:in `new_target'
/Users/***/.rbenv/versions/2.0.0-p247/lib/ruby/gems/2.0.0/gems/xcodeproj-0.13.0/lib/xcodeproj/project.rb:576:in `new_target'
/Users/***/.rbenv/versions/2.0.0-p247/lib/ruby/gems/2.0.0/gems/cocoapods-0.26.2/lib/cocoapods/installer/target_installer.rb:44:in `add_target'
/Users/***/.rbenv/versions/2.0.0-p247/lib/ruby/gems/2.0.0/gems/cocoapods-0.26.2/lib/cocoapods/installer/target_installer/pod_target_installer.rb:15:in `block in install!'
/Users/***/.rbenv/versions/2.0.0-p247/lib/ruby/gems/2.0.0/gems/cocoapods-0.26.2/lib/cocoapods/user_interface.rb:113:in `message'
/Users/***/.rbenv/versions/2.0.0-p247/lib/ruby/gems/2.0.0/gems/cocoapods-0.26.2/lib/cocoapods/installer/target_installer/pod_target_installer.rb:14:in `install!'
/Users/***/.rbenv/versions/2.0.0-p247/lib/ruby/gems/2.0.0/gems/cocoapods-0.26.2/lib/cocoapods/installer.rb:340:in `block (2 levels) in install_libraries'
/Users/***/.rbenv/versions/2.0.0-p247/lib/ruby/gems/2.0.0/gems/cocoapods-0.26.2/lib/cocoapods/installer.rb:337:in `each'
/Users/***/.rbenv/versions/2.0.0-p247/lib/ruby/gems/2.0.0/gems/cocoapods-0.26.2/lib/cocoapods/installer.rb:337:in `block in install_libraries'
/Users/***/.rbenv/versions/2.0.0-p247/lib/ruby/gems/2.0.0/gems/cocoapods-0.26.2/lib/cocoapods/user_interface.rb:113:in `message'
/Users/***/.rbenv/versions/2.0.0-p247/lib/ruby/gems/2.0.0/gems/cocoapods-0.26.2/lib/cocoapods/installer.rb:336:in `install_libraries'
/Users/***/.rbenv/versions/2.0.0-p247/lib/ruby/gems/2.0.0/gems/cocoapods-0.26.2/lib/cocoapods/installer.rb:113:in `block in generate_pods_project'
/Users/***/.rbenv/versions/2.0.0-p247/lib/ruby/gems/2.0.0/gems/cocoapods-0.26.2/lib/cocoapods/user_interface.rb:52:in `section'
/Users/***/.rbenv/versions/2.0.0-p247/lib/ruby/gems/2.0.0/gems/cocoapods-0.26.2/lib/cocoapods/installer.rb:110:in `generate_pods_project'
/Users/***/.rbenv/versions/2.0.0-p247/lib/ruby/gems/2.0.0/gems/cocoapods-0.26.2/lib/cocoapods/installer.rb:88:in `install!'
/Users/***/.rbenv/versions/2.0.0-p247/lib/ruby/gems/2.0.0/gems/cocoapods-0.26.2/lib/cocoapods/command/project.rb:38:in `run_install_with_update'
/Users/***/.rbenv/versions/2.0.0-p247/lib/ruby/gems/2.0.0/gems/cocoapods-0.26.2/lib/cocoapods/command/project.rb:68:in `run'
/Users/***/.rbenv/versions/2.0.0-p247/lib/ruby/gems/2.0.0/gems/claide-0.3.2/lib/claide/command.rb:206:in `run'
/Users/***/.rbenv/versions/2.0.0-p247/lib/ruby/gems/2.0.0/gems/cocoapods-0.26.2/lib/cocoapods/command.rb:51:in `run'
/Users/***/.rbenv/versions/2.0.0-p247/lib/ruby/gems/2.0.0/gems/cocoapods-0.26.2/bin/pod:19:in `<top (required)>'
/Users/***/.rbenv/versions/2.0.0-p247/bin/pod:23:in `load'
/Users/***/.rbenv/versions/2.0.0-p247/bin/pod:23:in `<main>'
amolloy commented Oct 9, 2013

Same here. In addition, I checked my project and SDKROOT is set the same for all configurations but I still receive this error.


Ditto. Downgrading to 0.26.1 reverts the issue.


Downgrading to 0.23.0 fixed it for me. It may work in later versions, but 0.26.1 was unusable due to ARC issues.


Having the same problem. Had to roll all the way back to 0.25.0 because of the ARC issues in 0.26.1.

lancep commented Oct 9, 2013

seeing this issue as well, anyone with the same problem, this will downgrade you to 0.26.1
sudo gem uninstall cocoapods --version 0.26.2
sudo gem install cocoapods -v 0.26.1


This appears to affect any project that has Configuration aside from the standard Debug and Release. It looks like Xcodeproj is expecting to see a uniform set of configurations across all the projects

kylef commented Oct 9, 2013

I think this was caused by CocoaPods/Xcodeproj@8911fee /cc @irrationalfab

mdarnall commented Oct 9, 2013

+1 having the same issue

CocoaPods member

@kylef indeed. The issue is tha we used to inspect only the first build configuration. To properly inspect the target now we look to all the configurations. Unfortunatly custom configurations often have empty build settings and the issue is more widespread than what I had anticipated. Sorry for the inconvenience.

At this point I'm not sure what Xcode does. I think that to resolve a build setting with the given key:

  1. Looks at the target current build configuration
  2. If empty it looks at the project.
  3. if still empty it looks for the default build configuration of the configuration list of the target.
  4. if still empty it looks at the default configuration of the project.

I'm not sure of the above but this is my best thesis. I'm not sure if there are some other sort of heuristics going on though. Unless somebody comes out with a more plausible explanation I will try this approach tomorrow (unless @kylef beats me ;-)).


This fallback logic should work fine. I’d bet everyone affected by the issue has the configurations added on the app target or the project itself


+1 same issue I've posted here with some screenshots of the actual setup

I have reverted back to 0.26.1 but that didn't fix it.
Now when building using second config "Debug Dev", build fails with "ARC forbids" errors

Is there any quick workaround we can do to get going?

x2on commented Oct 10, 2013

Same issue. Reverting to 0.25 with sudo gem uninstall cocoapods -v "0.26.2" fixes that issue.

CocoaPods member

After inspecting Xcode's behavior, I realized that the defaultConfigurationName attribute of the ConfigurationList is used not for resolving attributes but for picking a default configuration in the command line tools. For this reason I didn't used the strategy described above for the patch. Instead I'm relying on a heuristic approach where I simply discard blank values.

Btw, at least on recent versions of Xcode, if you duplicate a build configuration it carries the SDKROOT value. Not sure why that is not the case for you folks.

CocoaPods member

The following should fix the issue (remember to re-install the last CP version if needed):

$ [sudo] gem install xcodeproj
hufkens commented Oct 10, 2013

Thanks, that fixed my problem.

CocoaPods member

@blakewatters You're right! As I changed the behavior of the logic which analyzes the user targets I assumed that the issue was there without realizing that also the logic generating the Pod targets might have bee affected. Thanks for pointing it out to me. I also realized that there is another bug related to this.

CocoaPods member
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.