I'm running Xcode 4.3.2 on Lion and I have a very old Xcode 1.0 project whose targets are Jam-based. When I'm trying to build such a target, Xcode tells me that "Jam is deprecated and has been removed; targets that use Jam must be upgraded to native targets. For more information on doing this, consult the Xcode documentation.".
Unfortunately, neither could I find anything in Xcode 4's documentation, nor could I locate Xcode 3's "Project > Upgrade To Native Target" menu item anywhere in Xcode 4.
How can I do the target conversion in Xcode 4?
From the lack of answers I conclude that there are only two ways to achieve what I wanted:
Either set up Xcode 3 for doing the conversion or
Recreate the project by hand in Xcode 4.
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'm on macOS 10.13.3 and I created a new fresh macOS project with Xcode(9.2). Without any custom code I changed the Base SDK from 10.13 (wich is default) to 10.12 in the Build Settings of the target. When I build it I get this error: <unknown>:0: error: Swift does not support the SDK 'MacOSX10.12.sdk'. I also changed the version (Base SDK) to 10.2 for macOS Deployment Target. I also changed the two locations for the Project Settings. But it does not compile. I always get this error. I can't imagine that swift is not backward compatible. Even to change the swift version from 4 to 3.2 has no effect. Is there really no way to compile this new fresh project for SDK 10.12 or even 10.10? Any help is highly appreciated.
What I did before:
To be able to change the version of the BaseSDK within Xcode,
I downloaded the SDK's from here: https://github.com/phracker/MacOSX-SDKs. I edited the info.plist file in /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer There I deleted this two lines of code:
<key>MinimumSDKVersion</key>
<string>10.11</string>
Xcode 9 is quite similar to Xcode 8.
I'm building Apple's Open Source IOGraphicsFamily.
In the Products group there is a target called iogdiagnose. Its source produced many compiler errors when I tried to build all my targets, so I removed the group with iogdiagnose's source from my project.
But the iogdiagnose target is still there. It produces a link error - missing main.
Google failed to yield insight. There was the same question for Xcode 6.1, but Xcode 9 is quite different from 6.1.
Building the IOGraphicsFamily driver stack has been a huge PITA. I need my own build so I can enable the driver stack's kprintf logging.
Simply right-click on the target and click on Delete.
I deleted the target by editing the project.pbxproj that's in the .xcodeproj bundle.
That worked just fine however but there must a GUI to delete targets.
The great thing about Xcode is that Apple keeps us sharped-eyed by rearranging the GUI in profound ways with each new release.
After upgrading xcode to 8.0, my application project build with error for device target but building successfully for simulator.
Error is like:
ld: library not found for -lcrt1.3.1.o
What does the solution for this error.
After spending lots time, i finally got the reason for this error.
Error: ld: library not found for -lcrt1.3.1.o
Solution:
If your project source have deployment target from iOS 5.0 then change it to iOS 6.0 or later and your error will be fix. Now that work fine for device too.
Hurray!!!
crt1.3.1.o is a library that was included in older iOSes (and thus, their SDKs) but is no longer present in newer SDKs. However, when the project's Deployment Target is set to an older iOS (<6.0, as #Sandy has found), Xcode still tries linking against it.
To keep supporting iOS 5.x in newer Xcodes, one only needs to copy crt1.3.1.o from an older Xcode to the appropriate …/usr/lib/ dir in the newer Xcode. Xcode will only use crt1.3.1.o if the Deployment Target is <6.0— for projects with a Deployment Target ≥6.0 crt1.3.1.o remains unused and the resulting linked binary is identical to what it was pre-…/usr/lib/crt1.3.1.o-addition.
To get a newer Xcode to properly link a project with a iOS 5.x Deployment Target:
Download an older Xcode that still has crt1.3.1.o from https://developer.apple.com/downloads/.
I used Xcode 5.1.1, though any Xcode that has iOS 5.x support should work (which, according to Wikipedia should be Xcode 4.2-6.4).
Open the Xcode .dmg and on the disk image, locate the file at /Volumes/Xcode/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS….sdk/usr/lib/crt1.3.1.o.
Since I used Xcode 5.1.1, mine was at …/iPhoneOS7.1.sdk/usr/lib/crt1.3.1.o.
Copy to the same Xcode.app-relative directory in your newer Xcode: /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS.sdk/usr/lib/crt1.3.1.o.
My newer-Xcode at time of writing is the latest release, Xcode 8.1 (which out-of-the-box includes the iOS 10.1 SDK and downloadable iOS Simulator support back to iOS 8.1).
Note that you'll need to re-perform these steps after each Xcode upgrade, since the standard Xcode update process is to just blow away Xcode.app and everything contained within with the updated Xcode.app.
Also note that I've successfully tested this using Xcode 8.1 to produce an app with a Deployment Target of iOS 5.0 that'll run on both my iOS 10.1.1 iPad Air 2 & my iOS 6.1.3 iPhone 4S. I have not, however, submitted a build using this process to the iOS App Store. While it's unlikely that Apple's certification would have a problem with this (since it is after all their own iOS crt1.3.1.o library; and since there is no other way to build an app against the latest SDK while still supporting iOS back to 5.x, which is almost certainly something that some enterprise clients are still doing), I can't make a firm promise here.
remove the -lPods-(someCocoaPod) lines in the 'Other Linker Flags' list BUT only if $(inherited) is at the top. At first I was unsure, but the reassuring sign was that I still saw references to my cocoapods when I left the edit mode(inherited). I tested in debug and release, both of which were giving me errors, and the problem was immediately resolved
Instead of using the libraries from an older Xcode install, you can also just recompile them from sources: https://github.com/mringwal/csu-ios
I have an app written that compiles and runs fine in Xcode 4.2. I want to port it into Xcode 3.2 (I have the compatibility option check marked) but Xcode 3.2 gives me an error for some reason. Does anyone know what the issue with this could be?
Additional info:
Base SDK: iOS 4.3
The code in question:
[[self navigationController] pushViewController:adminViewController animated:YES];
Xcode 4:
Xcode 3.2:
Error:
! Expected expression before "adminViewController"
The Xcode project compatibility flags in Xcode 4 are quite redundant. The flag sets the underlying project format and doesn't handle support for the versions of the iOS SDK you're programming for and the versions of the Objective C language and runtime.
If you can open the project in Xcode 3 (as it looks like you can) then it's 'compatible' as far as Xcode is concerned. If you're seeing compiler errors then your issue is to do with running your code older/different versions of the iOS SDK / LLVM / GCC.