Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Already on GitHub? Sign in to your account

Problems with 64-bit Builds and Xcode 5 GM #1352

Merged
merged 8 commits into from Sep 20, 2013

Conversation

Projects
None yet
Pods was rejected as an implicit dependency for 'libPods.a' because its architectures 'armv7 armv7s' didn't contain all required architectures 'armv7 armv7s arm64'

I can try and update it myself, but in the future, Cocoapods should add the arm64 architecture to the pods when detected

👍

even updating it yourself doesn't seem to work. have all mine set fine and getting the same error.

Ah, perhaps somebody smarter than us will figure out what is really going on here then

dcloud commented Sep 10, 2013

🙀 I think this means I get to go home early.

Owner

fabiopelosin commented Sep 10, 2013

If I recall correctly you need to clear the architectures and let Xcode handle them. I guess that now we know why we got that warning for the Pod targets. I implemented the fix in the past but I had to revert because Xcode 4 was failing the build.

kreeger commented Sep 10, 2013

Xcode actually gives me this warning when I attempt to archive, and then it outright fails with this.

ld: library not found for -lPods

Hoping it's related otherwise I have no idea what it'd be. My app's deployment target is 5.1 through 7.0.

Owner

segiddins commented Sep 10, 2013

👍

sirvine commented Sep 10, 2013

👍 ...and yes, ld: library not found for -lPods is the Linker Error thrown, so its seems they are related.

nrj commented Sep 10, 2013

If you open your Build Phases you'll also notice that the Pods.xcodeproj dependency is missing and Xcode won't let you add it due to it being rejected as an implicit dependency. Trying to figure out a workaround...

kreeger commented Sep 10, 2013

How kind of Apple to surprise us with a brand new architecture a week before they expect to go live with our apps!

Owner

fabiopelosin commented Sep 10, 2013

So deleting the Architectures (ARCHS) build setting for all the targets of the Pods project fixed the issue for me. Can you confirm?

Can you clarify how you "delete the Architectures build settings"?

Owner

fabiopelosin commented Sep 10, 2013

For clarity the selection is the following:
Pods (the project) -> Pods (the target) -> Build settings

This should be done for each target.

screen_shot_2013-09-11_at_00 13 32

Owner

segiddins commented Sep 10, 2013

@irrationalfab I don't think it's redacted any more

Owner

fabiopelosin commented Sep 10, 2013

@segiddins you're right 😄

Confirmed, updated cocoapod gem, deleted Architectures from each of the Pods and was able to Archive & Submit successfully.

@fabiopelosin fabiopelosin referenced this pull request in CocoaPods/Xcodeproj Sep 10, 2013

Merged

Add support for Xcode 5 #91

Contributor

AliSoftware commented Sep 10, 2013

Confirmed here too.

Having the issue with cocoapods 0.24.0, but removing the ARCHS build setting in each target of the Pods project resolves it 👍

Owner

fabiopelosin commented Sep 10, 2013

The only issue that I have with this is that breaks CocoaPods installations with Xcode 4. I am of the idea that we should release can however I would prefer to check with @alloy tomorrow.

kreeger commented Sep 10, 2013

@irrationalfab delivers yet again. You, sir, have saved my bacon.

Owner

fabiopelosin commented Sep 10, 2013

@kreeger 🍻

Coverage Status

Coverage remained the same when pulling a4cfec2 on xcode-5-support into 31d5b99 on master.

sirvine commented Sep 10, 2013

As an aside: I was able to fix this by changing the Architecture settings to "Standard architectures (including 64-bit)", which is an option in the drop-down on Build Settings.

Errors gone after deleting but build still fails with no errors this time (gonna be fun to debug...). Awful nice of Apple to drop a new arch on us at the last minute.

Owner

fabiopelosin commented Sep 10, 2013

As an aside: I was able to fix this by changing the Architecture settings to "Standard architectures (including 64-bit)", which is an option in the drop-down on Build Settings.

@sirvine That is the default option, so clearing it is equivalent.

@holyprin Try cleaning the project (and ensure that you cleaned the archs for all the targets, and that you are not inhibiting warnings in the Podfile). Failure without errors is very suspicious.

I found it, seems it's an external library failing in the linker but didn't warn me. compiled libs always bite you in the butt on GM days...

Confirmed. This fixes the architecture problem. Still waiting on the patch for the cocoapods bundles with archive bug: #1329

Contributor

jhersh commented Sep 11, 2013

Any suggestions for CI until this is available? A way to automate deleting this setting in the Pods project?

@jhersh Get your CI running pod install with bundle exec.

See what I recommended here: #1329

Contributor

jhersh commented Sep 11, 2013

@mattyohe Jenkins is now purring along like... Jenkins? 👍

mlondre commented Sep 11, 2013

For the noob out there, what is the easiest way to install the CocoaPods gem with this fix?

Owner

fabiopelosin commented Sep 11, 2013

what is the easiest way to install the CocoaPods gem with this fix?

For clarity I'm expanding on @mattyohe comment.

$ gem install bundler
$ cd project_dir
$ touch Gemfile 
$ open Gemfile 
$ bundle install
$ bundle exec pod install

In your Gemfile you should paste the following contents:

gem 'cocoapods', :git => 'http://github.com/CocoaPods/CocoaPods', :branch => 'xcode-5-support'
gem 'xcodeproj', :git => 'http://github.com/CocoaPods/Xcodeproj', :branch => 'redacted-support'

temojin commented Sep 11, 2013

i have this error - is this related? I added the patch via bundle as above. still no go.

/Pods/GoogleAnalytics-iOS-SDK/GoogleAnalytics-iOS-SDK/Library/libGoogleAnalytics.a(GAITransaction.o), too many compact unwind infos in function anon for architecture i386

rayray commented Sep 11, 2013

@temojin I don't think it's related. The workaround for that is to build for a device. When building for simulator, I am getting that same error for a different library, but I can build for a device just fine.

@coneybeare I don't think this issue has anything to do with 64-bit. All I did was update the Active Architecture setting for Debug mode as Xcode 5 suggested and the "implicit dependency" error was eliminated.

@irrationalfab thx using this branch fix this issue.
any idea when master branch will include this?

camdez commented Sep 11, 2013

As a point of clarification, the behavior I'm seeing is that for the project level, Standard architectures (armv7, armv7s) is the default value for the Architectures key (i.e. what you'll get if you clear the key). Note that this does not include arm64. So be careful that you're not "solving" your 64-bit build issues by accidentally excluding the architecture.

At the target level you'll see the setting inherited from the project level, so which value you will see if you clear the key at the target level depends on what you have the project level setting set to.

Owner

fabiopelosin commented Sep 12, 2013

@camdez Indeed you might right. It is unclear to me if this is an UI problem of Xcode or not.

Owner

fabiopelosin commented Sep 12, 2013

With the last commit CocoaPods will set the architectures according to the value set in the integrated targets. This patch should be compatible with both Xcode 4 and Xcode 5.

Note: if you set the architecture of your iOS target to standard architectures (including 64-bit) the build might due to a linker error without tile. If the message includes ld: symbol(s) not found for architecture arm64 it could be the case that one Pod is (sadly 😄) using a prebuilt framework/library which has not been compiled for 64-bit (pod update might help though).

o_O getting a "Unkown register name 'q0' in asm" for Pods-libwebp after changing architectures... so helpful haha. I don't even know the which Pod this is a dependency for, going to investigate now.

It's a dependency on SDWebImage and looks like there is an open ticket for it already rs/SDWebImage#494

Why does this need a warning and why only use the first value? For instance, building for a device and the sim should already be two different architectures.

Owner

fabiopelosin replied Sep 12, 2013

Each user target will return nil or a string for the ARCHS setting (the string might include multiple architectures but it is a string). The warning is provided in the unlikely case where the user links the target definition to multiple targets with different ARCHs.

Owner

alloy replied Sep 12, 2013

Ah yes, it returns a string, not an array.

The warning is provided in the unlikely case where the user links the target definition to multiple targets with different ARCHs.

Still, is that not a valid case in your opinion? How about something like this where we actually collect all the archs?

archs = archs.compact.map { |x| x.split(/\s+/) }.flatten.uniq.sort
Owner

fabiopelosin replied Sep 13, 2013

Sounds like this would be the best solution!

Contributor

AliSoftware replied Sep 16, 2013

Not a major issue, but if archs.count == 0 (ARCHS setting deleted thus empty in all user targets, which is the case for a brand new xcodeproj created with Xcode5 GM), the warning is printed even if it makes no sense to warn about it 😉

Owner

alloy replied Sep 20, 2013

@AliSoftware Looking into it. Thanks!

Owner

alloy replied Sep 20, 2013

@AliSoftware Fixed in c33023c, as can be seen in the integration test fixtures: CocoaPods/cocoapods-integration-specs@6c1eb33.

Contributor

AliSoftware replied Sep 20, 2013

👍

Contributor

jeanregisser commented Sep 12, 2013

Awesome! The xcode-5-support branch fixed the problems we were having.

Also, not sure when the improvement on this was done but pod install with this branch is now much faster compared to the 0.24 released version.

With our complex Podfile, we saw the phases starting from "Generating Pods project" taking well over 3 mins with 0.24, to just a few seconds now 😃 !

So thanks for this huge speed bump!

Coverage Status

Coverage remained the same when pulling 003f92e on xcode-5-support into 31d5b99 on master.

zdsumit commented Sep 16, 2013

Yeah, this is the new Arch. introduced and when i was working, i got a warning saying update pods to recommended settings and over there, it edited all the pods to recommended archs and further this problem never came.
Now, again after some days i saw the same problem and that warning is not coming now.

@modocache modocache referenced this pull request in kiwi-bdd/Kiwi Sep 16, 2013

Closed

Adding Kiwi to my current project (Xcode5) #369

Contributor

AliSoftware commented Sep 16, 2013

Silly remark, but after installing the patch using bundler, if I bundle exec pod update on my project, on which I already have removed the ARCHS build setting manually before, I got:

[!] Found multiple values (``) for the architectures (`ARCHS`) build setting for the `Pods` target definition. Using the first.

I don't know if this is an error/typo in the warning message or if this is a real logic error in the code, but ('') does not seem to me to be an array with multiple values?
At the end everything works as my "Pods" project still has its ARCHS setting deleted, thus using the iOS Default, but maybe this inconsistency in the warning hides some real error in the code? (Maybe not, but better safe than sorry)

[EDIT] Actually I got the same error even if I run bundle exec pod install on a newly created project, so this does not seem to be affected by the fact that I already removed the ARCHS settings from my Pods project manually in my previous test


For info:

$ bundle show
  * cocoapods (0.24.0 003f92e)
  * cocoapods-core (0.24.0)
  * cocoapods-downloader (0.2.0)
[…]
  * xcodeproj (0.10.1 bc3a712)
Contributor

AliSoftware commented Sep 16, 2013

As a side note, Xcode5 GM always suggests to validate build settings on the Pods project and "Enable Build Active Architecture Only When Debugging".
I guess making CP set ONLY_ACTIVE_ARCH=YES in Debug config for each Pods target will solve this 🍺

@jzapater jzapater pushed a commit to jzapater/CocoaPods that referenced this pull request Sep 17, 2013

@orta orta Merge pull request #1352 from ursachec/master
[Update] AFQuickLookView (0.3.1)
db9db66

Fl0p commented Sep 18, 2013

👍

Since Xcode 5 is out, it would be great if this would be a part of minor CocoaPods release. Bundler is a workaround, but not for CI-server with lot of projects, which are all failing now for us =)

Owner

orta commented Sep 19, 2013

We're all out at NSSpain, there'll probably be a release next week once we've got back to computers etc.

Fl0p commented Sep 19, 2013

Lucky you, 🍷

@DenHeadless couldn't you get your CI server to run bundle install, and
bundle exec pod install?

Sent from my iPhone

On Sep 19, 2013, at 4:54 AM, DenHeadless notifications@github.com wrote:

Since Xcode 5 is out, it would be great if this would be a part of minor
CocoaPods release. Bundler is a workaround, but not for CI-server with lot
of projects, which are all failing now for us =)


Reply to this email directly or view it on
GitHubhttps://github.com/CocoaPods/CocoaPods/pull/1352#issuecomment-24725102
.

@mattyohe we can, of course, but this needs to be done to each project settings. Before every build Pods directory is cleaned, and pod install is performed. So every project will need to be modified, and then after new cocoapods get released we'll have to revert all these changes. It's not a deal-breaker, but having a new release would be nice =)

x2on commented Sep 19, 2013

+1 for a minor release with this fix. Many red builds here...

bm-i commented Sep 19, 2013

+1

+1

licx commented Sep 19, 2013

+1

zdsumit commented Sep 19, 2013

+2 :)

Owner

orta commented Sep 19, 2013

no more +1s please, we get it.

@DenHeadless you could actually change every project to always run bundle install if a Gemfile exists and then bundle exec pod install, and that could work beyond the release of 0.24.1, because then you would simply update your project's Gemfile, and it would put you in a position to prepare for this type of issue in the future.

@x2on do the same if you can.

@kexoth kexoth referenced this pull request in chute/photo-picker-plus-ios Sep 20, 2013

Closed

Compiling error on Sample app #47

@alloy alloy Merge branch 'master' into xcode-5-support
Conflicts:
	Gemfile.lock
	spec/cocoapods-integration-specs
f047715

Coverage Status

Coverage remained the same when pulling f047715 on xcode-5-support into 50e19ae on master.

Coverage Status

Coverage remained the same when pulling c33023c on xcode-5-support into 50e19ae on master.

There's no way we can install bundle install and bundle exec pod install if you are using Xcode 5 in a system superior to OSX 10.8

Coverage Status

Coverage remained the same when pulling ddcd6cf on xcode-5-support into 50e19ae on master.

Owner

alloy commented Sep 20, 2013

@ppaulojr Why not?

Coverage Status

Coverage remained the same when pulling f112953 on xcode-5-support into 50e19ae on master.

@alloy
Gem files will remain installed in /Library/Ruby/Gems/2.0.0/bundler/gems/Xcodeproj-d7bacd932526 for inspection.
Results logged to /Library/Ruby/Gems/2.0.0/bundler/gems/Xcodeproj-d7bacd932526/ext/xcodeproj/gem_make.out

An error occurred while installing xcodeproj (0.10.1), and Bundler cannot continue.
Make sure that gem install xcodeproj -v '0.10.1' succeeds before bundling.

And I did install the xcodeproj 0.10.1

The log file indicated has this

checking for st.h... no
xcodeproj currently requires the (ruby/)st.h header
*** extconf.rb failed ***
Could not create Makefile due to some reason, probably lack of necessary
libraries and/or headers.  Check the mkmf.log file for more details.  You may
need configuration options.

Provided configuration options:
        --with-opt-dir
        --without-opt-dir
        --with-opt-include
        --without-opt-include=${opt-dir}/include
        --with-opt-lib
        --without-opt-lib=${opt-dir}/lib
        --with-make-prog
        --without-make-prog
        --srcdir=.
        --curdir
        --ruby=/System/Library/Frameworks/Ruby.framework/Versions/2.0/usr/bin/ruby
Contributor

AliSoftware commented Sep 20, 2013

I got Ruby 1.8 on my OSX 10.8 and I installed bundler and the HEAD version of CP without any issue, contrary to @ppaulojr who seems to have Ruby 2.0 on his… 10.9?

So maybe @ppaulojr 's problem is related to Ruby 2.0 (and maybe deserve a separated issue on GitHub)?

kreeger commented Sep 20, 2013

I've been able to run the latest builds of cocoapods and xcodeproj on my OS X 10.9 / Ruby 2.0 setup just fine, even on the latest xcode-5 support branches.

Then again, I'm using a Ruby 2.0.0 that's provided by rbenv. I'm pretty sure this is a separate issue anyway. It's not related to Xcode 5 support.

Owner

alloy commented Sep 20, 2013

@ppaulojr @AliSoftware @kreeger Yeah this is a OS X 10.9 + Xcode 5 issue. You need a Xcode developer preview that contains the 10.9 SDK and fix the headers as described in #1108 / https://gist.github.com/goshakkk/5763489.

Coverage Status

Coverage remained the same when pulling 0ac79ea on xcode-5-support into 50e19ae on master.

@alloy alloy added a commit that referenced this pull request Sep 20, 2013

@alloy alloy Merge pull request #1352 from CocoaPods/xcode-5-support
Problems with 64-bit Builds and Xcode 5 GM
9374330

@alloy alloy merged commit 9374330 into master Sep 20, 2013

Coverage Status

Coverage remained the same when pulling 07b875d on xcode-5-support into 50e19ae on master.

+1, @irrationalfab Thank you, sir.

thx!

I've set the Build Active Architecture Only to YES for Debug on all my targets and I'm still getting

Pods was rejected as an implicit dependency for 'libPods.a' because its architectures 'i386' didn't contain all required architectures 'x86_64'

Is there any other config changes that need to be made?

Contributor

AliSoftware commented Sep 27, 2013

@zakdances did you delete the ARCHS build setting (to reset it to its default) too (as explained in this comment and below)?

.@AliSoftware Yes, still having the same problem. Same error message. In fact, after deleting the build settings for all pods, there is 2 additional clang errors:

ProcessPCH /Users/zak/Library/Developer/Xcode/DerivedData/MyApp-gdktazrejoumvbdqiadqqxylohnw/Build/Intermediates/PrecompiledHeaders/Pods-AFNetworking-prefix-gkegbehrndllxmfwvcurqbomhzlx/Pods-AFNetworking-prefix.pch.pth Pods-AFNetworking-prefix.pch normal i386 objective-c com.apple.compilers.llvm.clang.1_0.compiler
cd /Users/zak/Zak/projects/libraries/MyApp/XCode/MyApp/Pods
setenv LANG en_US.US-ASCII

error: -fobjc-arc is not supported on platforms using the legacy runtime
Command /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang failed with exit code 1

and

ProcessPCH /Users/zak/Library/Developer/Xcode/DerivedData/MyApp-gdktazrejoumvbdzpadqqoycohnw/Build/Intermediates/PrecompiledHeaders/Pods-Archimedes-prefix-eyssgyncjzbigcdxxzgsdmdqdhxt/Pods-Archimedes-prefix.pch.pth Pods-Archimedes-prefix.pch normal i386 objective-c com.apple.compilers.llvm.clang.1_0.compiler
    cd /Users/zak/Zak/projects/libraries/MyApp/XCode/MyApp/Pods
    setenv LANG en_US.US-ASCII

error: -fobjc-arc is not supported on platforms using the legacy runtime
Command /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang failed with exit code 1

What else can I try to fix all these errors?

Contributor

AliSoftware commented Sep 27, 2013

@zakdances Probably the same problem I'm having then here 😒

Even after rolling back to version 0.24.0 and 0.23.0 of Cocoapods, the same errors occur. Nothing will compile.

Is there a minimum OSX version or Xcode version that Cocoapods requires that could be an issue? How can I narrow down the cause these errors?

After manually settings the Architectures setting of all pods to 64-bit Intel, I was able to get all errors to disappear. I hope this helps anyone else seeing this issue.

I got this working by manually targeting only armv7 (removed armv7s) from ARCHS in command line build.

I'm still seeing this issue after trying all of the suggestions on this issue. Pods compiles and runs fine on the simulator, but doesn't run on the device.

Owner

alloy commented Oct 2, 2013

TO ALL STILL HAVING ISSUES

This ticket is getting too noisy. Please read the FAQ entry here that’s been extracted from the CHANGELOG.

If you had to preform more work, please create a new ticket and list the settings you needed to change.

@mtitolo mtitolo referenced this pull request in couchbase/couchbase-lite-ios Nov 13, 2013

Closed

Should be installable via CocoaPods #39

Why build active architecture only for debug builds and thus require the extra Xcode setting in our projects? Why not just have Cocoapods build all architectures for debug like it does for all other configurations? I guess it's faster to build only for the active arch, but this seems complicated an introduces confusion and support issues for cocoapods.

Is there a compelling reason not to have cocoapods just build all architectures for all configurations, including debug?

Thanks!

Building for active architecture only is the default for new projects in Xcode 5.

OK, that's fair then. I'm using this in a project originally created in Xcode 4, so I guess that's why I had the issue then. But I imagine lots of others will have the same problem.

Thanks for letting me know.

@alloy Your FAQ link forwards to http://guides.cocoapods.org/using/faq.html, which doesn't address this issue.

Contributor

kylef commented Feb 18, 2014

@getaaron This information should be available in the troubleshooting guide.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment