Xcode 12 build target in wrong order for simulator? - xcode

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.

Related

xcode not building arm64/apple silicon universal dylib

I am on xcode 12.4 macOS catalina, Intel x64 machine. There is a project which is C/C++ project and outputs a dylib. In the xcode 12.4 the build setting "Architectures" is Apple Silicon & Intel.
Build active architecture Only is No.
The dylib builds fine but when I check if it is a Universal library or not using lipo then it shows on x64 and not arm.
I signed up just to post an answer, cause I spend couple of hours myself with the same problem.
There's a setting 'Allow Multi-Platform Builds' under 'Build Options', that should be turned on. It did the trick for me and now it compiles a 'fat' dylib.
Confusing thing is that for the bundles, it compiles the universal binary with this setting turned to off, but not for the dylib's.
I've just chased down my problem with a similar scenario, but with an application target. I had copied an FCPX project (created on Xcode v10.*) to a new project intended to support 'arm64' and
x86_64'. Since I was using *.xcconfig settings, I did not expect any problems - but, sure enough, arm64 was NOT built because of a "stray" setting for VALID_ARCHS that restricted the target to x86_64. But Xcode 12.2 no longer displays the "Valid Architectures" setting in the ui (this was the root of my confusion). At any rate, I fixed my issue first by adding a VALID_ARCHS setting (which included arm64) to the *.xcconfig file. The final solution was editing the project.pbxproj file, and discarding the VALID_ARCHS setting.

Linking dual (iphoneos and watchos) frameworks with same product name

I recently had to duplicate my own frameworks to be able to link them from the native watchOS 2 extension, because the platform is different. So for every framework X I have an X-watchos counterpart.
Everything works fine in the simulator and when building directly to my devices, and it wasn't until I tried to archive that I got this linking error:
I ran lipo -i on the built watchOS framework and sure enough, its archs are arm7 and arm64 instead of armv7k.
When I looked further into the built directory I noticed this:
Both versions are symlinks to the same file, and because the have the same product name, they're being overridden. I could make them have different names, but that would make importing them really cumbersome.
Note that this is not a problem for 3rd-party frameworks because Carthage is already building them in separate directories.
EDIT 08/22/2015: I've filed a radar with a sample project: http://www.openradar.me/22392501
EDIT 08/24/2015: This has been acknowledged in Xcode 7 Beta 6 release notes as a known issue:
EDIT 09/9/2015: Xcode 7.1 Beta release notes hint that this is fixed, but I haven't confirmed it yet.
This is working for me in Xcode 7.1.
I’m using a similar configuration with my own frameworks, but I set a different name when creating it in each platform (MyFramework and MyFramework-watchOS). Don't forget to set a common product name manually (mine is MyFramework on both) in the build settings tab of each framework.

Xcode 7 bitcode_strip error

My Xcode 7 beta3 project includes some framework compiled by Xcode 6, these frameworks are imported to my project by Embeded Frameworks option in "Build Phase" tab. Because these frameworks does not support bitcode, so the "Enable Bitcode" option turned to NO, when compile the project, Bitcode_strip error occurred:
/Applications/Xcode-beta.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/bitcode_strip
/Users/panzhansheng/Desktop/MusicFans_2.0.4_xcode7_autoplay/MusicFans/Frameworks/FLAC.framework/FLAC
-r -o /Users/panzhansheng/Library/Developer/Xcode/DerivedData/MusicFans-bxutvotiungdbwfsxloykffnqoqs/Build/Products/Debug-iphoneos/MusicFans.app/FLAC.framework/FLAC
/Applications/Xcode-beta.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/bitcode_strip:
input file must be a linked Mach-O file not an archive:
/Users/panzhansheng/Desktop/MusicFans_2.0.4_xcode7_autoplay/MusicFans/Frameworks/FLAC.framework/FLAC
(for architecture i386) error: bitcode_strip
/Users/panzhansheng/Desktop/MusicFans_2.0.4_xcode7_autoplay/MusicFans/Frameworks/FLAC.framework/FLAC:
/Applications/Xcode-beta.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/bitcode_strip
exited with 1
I found that the error happened when Xcode copy my frameworks to my App package and try to strip bitcode from the framework, but these frameworks were compiled by Xcode early version and did not include bitcode at all. How to fix this? Thanks!
As I found out, XCode uses bitcode-strip only when enviroment variable STRIP_BITCODE_FROM_COPIED_FILES is set to YES. It seems that it's set to YES by default when enable_bitcode is switched on.
Adding User-Defined Setting STRIP_BITCODE_FROM_COPIED_FILES=NO to your Target can help you, XCode will not use bitcode-strip, but your app which will use frameworks without bitcode section probably will not work. So it's better to recompile them also using STRIP_BITCODE_FROM_COPIED_FILES=NO if necessary.
Tested on XCode 7 beta 5
following up on M. Pogosskiy's answer, it took me awhile to track down where to put the STRIP_BITCODE_FROM_COPIED_FILES bit setting (not too familiar with these). for reference, here's an illustration:
It was due to low memory/ disk space available in Mac system. When I cleared it. It runs smooth without cleaning itself.

Xcode cannot run using the selected device after upgrade to Xcode 5.0

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.

iWebDriver - iphone Selenium

I have gotten this to work before so I know its possible, but trying it on a new machine.
I have OS X 10.8.2, Xcode 4.6, iPad 6.1, and trying to do this:
Iphonedriver selenium
I get to the point where I am building the project in Xcode and get this error:
Check dependencies
No architectures to compile for (ONLY_ACTIVE_ARCH=YES, active arch=armv7, VALID_ARCHS=i386).
My architecture is set to: Standard(armv7,armv7s),
Build Active: Yes,
Valid Architectures: armv7s armv7,
The project is code signed. Any help is appreciated. I know i missed somehting obvious. Let me know if I left anything out or you need more info. I have looked at the following SO questions, and other similar ones:
SO Link1
SO Link2
I was hopeing someone had specific experience with iWebDriver. I will eventually be using this in a GRID 2 configuration.
“armv7 armv7s i386” is what it wanted on all ‘Valid Architectures’ fields (debug and release) for both the project and target!
I got the same error in the build settings configurtions, got it fixed with below:
Architectures --Standard(armv7,armv7s) - $
Valid Architectures --i386 armv7s

Resources