I just updated to xcode 5.1 - apple decided to make all apps compile to 64bit by default - My app has some legacy code and I spent the last couple of hours figuring out how to STOP Xcode building for 64bit. Thought this might help people with the same problem...
See the accepted answer for a clearer visual walk thought
(my original text based answer...)
In Targets-->Build Settings-->Architectures-->Architectures
select other
delete (press '-') $(ARCH_STANDARD)
add (press '+') armv7
add (press '+') armv7s
clean and build
OP is posted the solution along with the question itself. But I feel it would be better to add it as an answer. In Xcode 5.1 apple made significant changes to the architecture section. They made arm64 as part of Standard architectures. That means the projects using the default setting will be automatically build for arm64 also. So what you will do if your app does not support arm64?.
Doc says:
Projects not able to support 64-bit need to specifically set the architectures build setting to not include 64-bit.
How to do that?
Goto Targets-->Build Settings-->Architectures-->Architectures
Double click on the architecture will popup a menu. Choose others
Delete the existing row - $(ARCH_STANDARD). Add the required architectures one by one
Now your architecture section will look like this
Or just use $(ARCHS_STANDARD_32_BIT)
Related
My project always runs correctly on all devices using Xcode 11, but after I installed Xcode 12 beta 4, it is failing to build on the simulator.
I compared the build logs of Xcode 11 and Xcode 12 and it seems in Xcode 12 that my main target is being built before the cocoa pods target, and so the link will fail because the cocoapods library will not be found.
How to fix the order of the build target?
In Xcode 11, everything is fine. My own target is built after the cocoapods target .
In Xcode 12, the build is out of order My own target is built before the cocoapods target .
OK, i got a solution to make the build work (this way to fix problem is not correct , the right way to fix is added in my update):
1 you need to add the Pods project to your main project as a external project
2 add all the cocodpods target as dependency explicitly in your main project 's build phase
But i still think may be the new beta version of xcode 12 will fix this. because it seem a bug of xcode 12 (my project work perfect in xcode 11 and xcode 12 + ios device , failed in xcode 12 + simulator only)
###2020-08-17 update###
i found a more exactly reason to reproduce this problem , it seems my project file open in xcode 12 will auto generate a VALID_ARCHS macro in User-Defines , and this macro will make the build failed
And i found that ,with this macro , During in the LINK of building,the link target type will be a unknown type
'arm64-apple-ios11.0-simulator'
which cause the build faild and the problem that all the targets build in wrong order seems will only happen when this macro is being added
XcodeDefault.xctoolchain/usr/bin/clang -target arm64-apple-ios11.0-simulator
after i delete this VALID_ARCHS macro, the link target type will be 'x86_64-apple-ios11.0-simulator' , and everything goes well
XcodeDefault.xctoolchain/usr/bin/clang -target x86_64-apple-ios11.0-simulator
####2020-09-11 add Add Apple's Feedback about this macro####
update Apple's Feedback on VALID_ARCHS
After reviewing your feedback, we have some additional information
for you:
Xcode does not add VALID_ARCHS to your project. Indeed, we recommend
against using VALID_ARCHS. Maybe some CocoaPod is setting it in your
project for some reason? CocoaPods are not part of Xcode so, we don’t
have any control over what they do.
One thing to note is that in Xcode 11 VALID_ARCHS showed up under the
architectures section. Since we are strongly recommending against
using it, it no longer shows up there and now appears in the User
Defined section if it is defined at all.
Xcode 11 used to automatically translate building for arm64 for the
simulator into building for x86_64, but now that arm64 is a valid
simulator architecture (it’s the Apple Silicon architecture), that
translation no longer occurs.
So, we suspect what you should do is delete VALID_ARCHS from your
project altogether, and make sure Architectures (ARCHS) is set to
Standard Architectures (ARCHS_STANDARD) and not to something specific
(unless you really know exactly why you’re not using ARCHS_STANDARD).
####Feedback end####
####2020-10-10 added####
the build may still not working after deleting the VALID_ARCHS macro for some guys , you may check the answer of Apple's feedback added and #Andrei Herford's answer below:
make sure Architectures (ARCHS) is set to Standard Architectures
(ARCHS_STANDARD)
and then delete the macro ,hope these two steps works for all:)
####2020-10-10 added end####
I was able to solve the problem both in simulator and on device by using $(ARCHS_STANDARD) not only for ARCHS in the Architecture settings but also in VALID_ARCHS as well. I am not sure what possible side effect changing the archs in this way might have but so far I have not experiencend any new problems.
Details:
The excellent answer by #ximmyxiao got me on the right track. However, the solution proposend by him (remove VALID_ARCHS) did not work for me. This led to a new problem when compiling the Pod targets (Command PhaseScriptExecution failed with a nonzero exit code and ARCHS[#]: unbound variable in Pods script).
Instead replacing arm64 with x86_64in VALID_ARCHS solved the problem when building for simulator. It seems that arm64 was never a correct platform and was translated to x86 by Xcode. As Apple has announced their shift to ARM processors, this translation is not correct anymore and thus one has to use the the correct platform x86_64 instead.
Regarding to Apple VALID_ARCHS should not be used any more. However, this fix did not work when building for devices. Eventually using $(ARCHS_STANDARD) instead (both for simulator and device) did the trick in both cases.
Good look to others who encounter this kind of problems. Never gets boring working with Xcode....
** For XCode 12.4 **
I have Apple MB Pro with M1 and the project with Moya POD and lot of others.
App builds perfectly in old intel-based macbook with the same version of XCode (12.4).
But for M1 it won't compile says: "Moya not found". What??
It said: "Could not find module 'Moya' for target 'x86_64-apple-ios-simulator'; found: arm64, arm64-apple-ios-simulator".
No suggestions worked for me. So what helped me is:
(not sure whether this is necessary): reinstall all pods by pod install
clear build data
launch via Rosette (check this in XCode app properties cmd+i)
in App's Project:
"Architectures": add x86_64
"Build Active Architecture Only": YES
in "Pods" project, conflicting pod section (Moya in my case):
"Build Active Architecture Only": YES
Then rebuild. Probably next rebuild also required.
For Xcode Version 12.1
If you can't find VALID_ARCHS
Adding **$(ARCHS_STANDARD) x86_64 i386 all three in Architectures will solve the issue for running on simulators and Devices , archiving . also suggestedly add Build Active Architecture Only to 'Yes'.
Here's what worked for me.
Removed VALID_ARCHS from user defined settings
Set the ARCHS to $(ARCHS_STANDARD)
Created a new .xcconfig file for my project. (If you already have one, then you may skip this)
Added these to my .xcconfig file
EXCLUDED_ARCHS[sdk=iphoneos*] = x86_64
EXCLUDED_ARCHS[sdk=iphonesimulator*] = arm64
After that, I'm able to build both for simulator & device. The idea here is to exclude arm64 when building on simulators and x86_64 on devices.
I upgraded to xcode 5.0 today. I then pressed play to run my project in the iOS simulator. This initially worked. Then I decided that I wanted to run the profiler. When I did that, I got the message:
Xcode cannot run using the selected device.
Choose a destination with a supported architecture in order to run on this device.
I looked at a couple past posts on this problem and decided to do a Clean and Build. Now I can no longer run in the profiler or the simulator. I consistently get the message:
Xcode cannot run using the selected device.
Choose a destination with a supported architecture in order to run on this device.
How can I resolve this?
Here are various settings:
My Deployment Target is 6.1
I have also tried changing the deployment target to 7.0, but that did not work either
It appears that the problem is not related to the architecture in the build settings as the error might suggest. Rather, I found that the problem seems to be related to the Build Options Compiler for C/C++/Objective C. I was using a gcc compiler (com.apple.compilers.llvmgcc42) and Xcode 5 has marked this as unsupported.
If I change the compiler to apple's default Apple LLVM 5.0, the project builds and it can now run in the simulator. The downside is that I have a lot of compiler warnings from code related to cocos2D v1.0 source code. But, at least I have a way forward.
Please follow below step
1>Go to Project Build setting
2>Change compiler for c/c++/objective c as Default compiler(Apple LLVM 5.0) (see in below image)
I had to change compiler for Default compiler (Apple LLVM 5.0) at two places:
Build Settings > Build Options > Compiler for C/C++/Objective-C (change to LLVM)
Build Rules > Files *.mc using GCC (change to LLVM)
Hard to find because code compiles even if Build Rules point to an undefined compiler.
After inspecting all the build settings for 15 minutes, this worked for me (Xcode 5.0.2):
Quit and restart Xcode
Check that the Executable File (also known as CFBundleExecutable) in the Info.plist file is set to ${EXECUTABLE_NAME} as opposed to any hardcoded value. This will ensure that even if you change your project name or target name or scheme name, that it still works.
This issue often occurs after duplicating targets on older projects.
Set the following in your Info.plist for the target:
Bundle Name = ${PRODUCT_NAME}
Bundle Display Name = ${PRODUCT_NAME}
Executable file = ${EXECUTABLE_NAME}
Build and run with these settings, after a successful build they can be changed to anything you want.
This works for me: "Quit and restart Xcode". I recently updated something and the testing device on Xcode said: 'iDevice' not iPhone or iPod. So I restarted then my iPhone came back to the target list.
I had this error when I changed the value of the "Bundle name"-key in the Target Properties. Changing it back to "%{PRODUCT_NAME}" solved the problem for me.
I've just upgraded to iOS5 / Xcode 4.2 and I'm now trying to submit an application to the App Store. When I try to validate my Archive, I get an error saying:
iPhone / iPod touch : application executable is missing a required architecture. Atleast one of the following architectures must be present: armv6
I've checked a few similar questions and the most of the accepted answers just said set the Build Active Architecture Only to NO. I've done this already and I still have the same issue. Here are my keys:
Architectures:
Distribution: Standard (armv7) - $(ARCHS_STANDARD_32_BIT)
Base SDK : iOS 5.0
Build Active Architecture Only: NO
Valid Architectures: armv6 armv7
Any help on how to fix this is much appreciated!
Thanks,
Teja
EDIT: Also added key armv6 manually to the Architectures section in the Build Settings. No change.
Setting the Target to iOS 4.3 will get rid of the App Store error, as iOS 4.3 requires armv7 and is not supported on the older armv6 devices.
I had to add the armv6 key manually to the Architectures section of the Target that I was archiving.. not the whole project. This worked to get my submission to the AppStore done, but I'll hold out for a better answer.
To continue to support the older architectures (e.g. iPhone 3G), just select your app target and select "Build Settings". At the top, change the Architectures listed from "Standard (armv7)" to "Other". In the pop-up box, select the existing option and click the minus button, then click the plus button and add "armv7", then again click plus and add "armv6". armv7 will support the newer chips, while armv6 will add back in support for the iPhone 3G... providing you set your iOS Deployment Target to iOS 4.2 or earlier... your setting at 3.x should be just fine—that merely limits you to not using newer features of iOS obviously.
You may also need to add "-mno-thumb" under "Other C Flags" in the Build Settings, though if my memory serves me correctly that may only have been if you are wanting to use Automatic Reference Counting on the old architecture—and even then only because this is a work-around for a known bug.
I have a framework of code I maintain. It's got mac and iphone objective-c code. And some of it is shared. I'm not having any problems with code. It's a problem with Xcode.
Let's just call my framework "AwesomeKit" for this problem.
The first thing I did was create an xcode Framework project called "AwesomeKit". Add source files to it, link against the common mac frameworks: foundation, cocoa, carbon, etc. It compiles fine.
Then, add a new "static library" target, let's call it "AwesomeKit-iPhone" and set the base SDK in the build settings to iphone device 3.1.3.
The problem comes when I try to add "Existing Frameworks" to the AweseomKit-iPhone target.
First change the current build target to AwesomeKit-iPhone.
Right click on any group and select "Add > Existing Frameworks..."
Choose UIKit.framework
UIKit will immediately be highlighted red, as if it's missing. It is indeed missing because Xcode uses the "Relative SDK" setting from the "Mac OS 10.6" SDK. When it should be using it relative to the current target's base sdk iphone device 3.1.3.
What the heck? Has anyone experienced this? This is really annoying.
I found the solution to this. You have to edit the project.pbxproj file inside of the project.xcodeproj directory. Find any entries like "SDKROOT = XXX" and change it to you real base root. It's probably best to look another project.pbxproj file that has it correctly set. I've used this on multiple occasions now and works like a charm. Usually there's 2 or more of the SDKROOT entries in project.pbxproj.
I think I've seen your problem. I'm still new myself to this, but what I've found when universal static libraries for both simulators and devices is that it's best to keep the Xcode Active SDK set to "Base SDK" rather that selecting an SDK. IN that mode, the current SDK is the SDK of the currently selected target.
Active SDK is rather like overriding the sdk on the command line. If yoy set it, SDK settings on targets will be overridden.
So im my case I wanted two targets to be run at the same time, one using the simulator sdk which compiles for i386 architecture and the other pointing at the device sdk which builds a universal lib for armv6/armv7 architectures.
I have seen the red not found stuff and I seem to remember that doing this, made it go away. I also had the project SDK set to a device rather than Mac. Remember that targets override this so it's a good way to ensure that Xcode is pointing at the right sdk without effecting the settings on targets and the ultimate build.
I'm in the same boat right now, XCode keep tacking the wrong SDK in front of the frameworks. This is project with both OSX and iOS targets. But there's seems to be something really wrong with my Project Build settings. Your screenshots don't show them, but you may want to check them. In my case, many entries are duplicates. So I have two categories "Architectures", totally identical. If I change one, the other changes along with it. This could be related to the problem with the wrong SDK being chosen. I think the project file is corrupted, and I'm now trying to figure out if I can fix it manually.
I have a project for Mac OS X 10.5 that I'm building on 10.6 using Xcode 3.2. When I use GCC 4.2 for Debug build and hit a breakpoint, Xcode debugger displays local variable information normally. If I choose LLVM GCC 4.2 or Clang LLVM, when I hit breakpoint, local symbols are not available, and GDB says No symbol 'self' in current context if I try to print self or any other local symbol. In all cases Generate debug info option is set. The Debug configuration is set to $(NATIVE_ARCH) and 10.5 SDK, Build active architecture only option is set. When GDB starts, I can see it is being configured as x86_64-apple-darwin. I must be missing something obvious. How do I make GDB show local symbols when using a LLVM compiler?
For those not familiar, a little more detail to cdespinosa's answer, which worked for me, and which I voted up.
From the Xcode menu, select Project > Edit Project Settings...
Choose the Build tab
In the search box type "Optimization Level", choose that field, and select None.
Next search for "Debug Information Format", choose that field, and select "DWARF" or "DWARF with dSYM".
Would have put this in comments to his post if I had the privs. ;)
This cost me some serious time, and was frankly kind of sloppy on Apple's part, but in general I can't complain.
Make sure you're building with Dwarf symbols and no optimization. llvm is a new back-end, and not all of its optimized codegen is hooked up to debug symbol generation yet.
This may help. Try turning off "Link-Time Optimization" in the project's build options. That fixed a problem I had with missing debug symbols.
In fact, that fixed a bunch of weird problems I was having with Clang. I'd say that feature is just too bleeding edge to use yet.
GDB from FSF only added support for JIT code very recently.
I don't know whether Apple-supplied GDB has support for it at all (do you get reasonable stack traces?). If it does, this support is (apparently) incomplete.
I was having this problem and solved it by putting a tick next to the menu item: "Project > Set Active Build Configuration > Debug". Previously, the "Release" option was selected. Locals started showing up in the debugger for my project from then on.