I have an iOS project that I've put in Dropbox to work with a few friends. The issue is that it seems to get "corrupted", so that after some time (after someone else has accessed the Xcode project file), when I try to go and open it again I get a Base SDK Missing error. In the Project Settings, I discover that I'm missing the valid ARM6/ARM7 architecture for iOS apps—I can only choose from 32-bit or 64-bit Intel. My only other options are i386, various forms of PPC, and x86_64. I simply can't build for iOS anymore.
No one else that I'm working with seems to have this problem. It exists in both Xcode 3 and 4, so it's not an Xcode 4 issue either.
Is anyone else having this problem? Is there a fix?
In these cases it's often a good idea to 'Clean All Targets'. I have found that particularly after upgrades to XCode where platforms or architectures have changed, that XCode can become confused about the state of previous builds. Cleaning, then re-specifying your desired targets/architectures/etc and then rebuilding will work well.
Also don't forget that if you hold Alt (or Option) down when you click on the Active build settings drop down will give you additional options.
Can you reinstall XCode? Also, it might be wiser to host the project under source control.
Hehe...turns out that the project had been used under the 4.2 SDK and at the time I only had 4.0, which explained the missing SDK part...Updated to 4.2 and it's all fixed now.
Source control would've been nice, but there aren't that many good ones that support the features we need (for free); if anyone's got a guide to installing Subversion on OS X and using it (without being too technical read Terminal), I'd appreciate that. Or how to set up Git with Xcode 4 (although I know that's under NDA, so that's probably not going to happen).
Related
I am trying to compile a "WebViewGold" ios app on an M1 processor MacBook Pro, using XCode latest (13.4.1) version.
I have greatly struggled to find a solution to those XCode error codes.
I have browsed related answers in threads like: building for iOS Simulator, but linking in object file built for iOS, https://stackoverflow.com/questions/32687105/framework-not-found-in-xcode,https://stackoverflow.com/questions/9458739/ld-warning-directory-not-found-for-option.
Nothing mentioned in the above answers worked!
Any idea about what I should do?
There is a possible, very simple solution provided by this answer.
Basically, freshly upgraded versions of XCode (for example, 13.4.1) running on Apple Silicon-powered Macs (like my M1 MacBook Pro), have components that cannot properly use/output the appropriate object files in all the output platform combinations you need.
This leads to some "interesting" issues and error message cross-overs that find "almost correct" answers on StackOverflow. Hence the many suggestions to exclude "arm64" platform and similar from the build options.
The simple answer to all of that is... to just run XCode with Rosetta enabled. Rosetta will engage with the components that miss the needed cross-platform capabilities.
Here is an example of how to enable an application to use Rosetta.
You select the app icon, then go to the File menu and select "Get Info".
Then click the "Open using Rosetta" checkbox.
It does seem that Build Active Architectures Only = NO is the issue, at least in Debug mode. I can successfully produce a Release archive, so I'd suggest just leaving it alone unless you're trying to debug the Intel version. Try a library, as you can ship the binary that way.
i recently received my Macbook and wanted to start developing iOS apps with it.
I Created a default Master-Detail App using the Templates in Xamarin.Studio and everything worked.
Now today i wanted to actually do something in the app, but didn't change a single line of code, still the app doesn't show up anymore in the simulator as long as i want it to use the 6.1 sdk for ios. if i use any other (6.0 etc) it works fine.
I already tried clearing my Cache in /Users/MYNAME/Library/Xamarin/ but this didn't change anything.
What would you suggest me to do now? can i simply reinstall the 6.1 sdk?if so, how would i do this?
Thanks for your help
I had a similar problem where the environment hang when I was trying to debug in the simulator (just showing the spinning ball). I found out that it only occured if I had my phone connected to the computer. Perhaps not valid in your case, but it might be a lead in your problem solving.
I'm using the latest version of everything. :)
From within Xamarin Studio (or MonoDevelop):
Project -> Your.Application.Name Options
Build -> iOS Build (iPhone Build in MonoDevelop)
SDK version: -> 6.1 (it's probably still on 6.0)
This fixed it for me. Also, it wouldn't hurt to make sure the target build in info.plist is set to 6.1.
Delete this folder:
/Users/[username]/Library/Application Support/iPhone Simulator/6.1
And if your Library folder is hidden:
sudo chflags nohidden ~/Library/
I have experienced this problem several times again and my previous answer doesn't solve it. Ya know what does? Rebooting the computer. Works every time. shrug
You need to fill the Application name, Identifier, Version # in the project setting.
I had the same problem and got it solved that way.
As always when Apple updates OS X, the latest XCode 4.4 dumps the older (10.6) SDK and I find myself needing to use the 10.7 SDK (or 10.8 I suppose) and setting my deployment target to 10.6 to maintain compatibility.
I prefer linking to the older SDK because I know that I cannot by mistake introduce calls to APIs that do not yet exist. Something that I found myself doing regularly when I last tried the inverse approach.
What I find myself doing is that I use the code completion feature in XCode to choose the "right" call for a simple class like NSWorkspace, then everything works fine during development, I forget about it and when I release a new version: Kaboum! The whole application explodes on earlier OS X releases at run-time; often in those hard-to-reach places :-)
Or at least this was the situation for me a few years back.
Surely, by now there's a way to either:
making sure you don't introduce API calls that are not yet available in your deployment target even if though they are defined in the SDK
detecting such calls during build or static analysis time
I'm sure I've missed something, somewhere along the line.. Please enlighten me!
Best regards,
Frank
Surely, by now there's a way to either:
making sure you don't introduce API calls that are not yet available
in your deployment target even if though they are defined in the SDK
detecting such calls during build or static analysis time
No there is not. Yes, you should open a radar (bugreport.apple.com) against it. If you like, you can dupe mine: rdar://11985733
Yes, the only viable solution, despite Apple's recommendation, is to copy the old SDKs and link against them.
I spent quite some time talking with the Xcode team about exactly this issue at WWDC 2012. They agreed that it's broken. There is not currently a plan to fix it. Escalating radar's is how we influence Apple on these things.
I'm generally copy SDK from older versions to the newer one so that compiler will blain me if i use something not supported.
Also you can simply look at Quick Help when calling some methods that you are not sure about, like in screenshot you can see that launchApplicationAtURL method is only available from 10.6
I've had this annoying problem on iOS too. It's actually even more annoying on iOS as the user has to sync their device with iTunes and enable crash report sending before the crash report gets sent unlike Mac OS X where you don't need to do all that. Recently, I managed to add a compile-time check for checking APIs against older versions of the SDK. I'll first explain how I did it for iOS first and then try and help you to adapt this technique for Mac OS X. I don't code much for Mac atm so I can only really guide you in the right direction from my experience with iOS but I'll test my suggestions later today once I get back from work and give a definite answer.
So here's what I did for iOS:
I first had to get the older Simulator SDK I wanted to get. I could easily get this by downloading older Xcode 3 (not 4) versions which included the SDK needed.
I next had to install the SDK. This wasn't too hard, so I won't explain much here. But the SDKs are stored in the Packages folder. This folder is clearly visible in earlier Xcode 3 versions but is hidden in later versions. You can easily open it anyway through Terminal. Also, after the change in Xcode 4.3 where the Developer folder moved to within Xcode.app, so I had to install the SDK into a tmp folder and move the SDK into Xcode.app yourself. I would then need to restart Xcode if I had it open.
After that, I duplicated my debug configuration in your project and named it, in my case, something like iOS 4.3 API Check or something like that - doesn't really matter. Then I changed the Base SDK of this new configuration to the old SDK which I installed. The SDK I installed was not listed though so I had to select other and enter, again in my case, iphonesimulator4.3.
Finally, when I needed to check against older versions of the SDK, I changed the configuration for the Run <appname>.app in my project scheme to my iOS 4.3 API Check configuration. And there we go, a compile-time check against iOS 4.3.
As for Mac OS X, I'm sure you can achieve the same goal with this same method. There isn't Simulators for the Mac SDK so I think the regular SDK will work for this. As for getting the older SDK, if you have Xcode 4.2 still installed (after Xcode 4.3 changed it so the Developer folder is within Xcode.app) then you should find the 10.6 SDK there. If you don't, I'd imagine that Apple has a similar thing to iOS where the SDK downloads are available in the Dev Center or somewhere on the internet...
As for setting the Base SDK, if it's not listed then I think the name is MacOSX10.6 or whatever version you are after.
Everything else should be the same, but as mentioned earlier, I'll test this method later today and edit my answer to give a more definite answer but I would imagine this method would work for the Mac SDK.
i also assumed that the compiler will warn me about "too new" API usage for the deployment target OS version. but it turned out that the compiler doesn't warn you about it by default. one of the reasons might be you could still use the new API by checking the availability during runtime with "respondsToSelector:", for example, on a newer OS version even when the deployment target version was older. you would need to add the compiler option -Wpartial-availability which is available on Xcode 7.3+ (to be confirmed) in order to get the "warning: 'something' is partial: introduced in macOS 10.x" warning message.
on macOS 10.12.3 with Xcode 8.2.1:
$ cat foo.m
#include <Foundation/Foundation.h>
BOOL foo()
{
return [#"foo" containsString:#"bar"];
}
$ cc -mmacosx-version-min=10.9 -Wpartial-availability foo.m -c -o foo.o
foo.m:5:20: warning: 'containsString:' is partial: introduced in macOS 10.10 [-Wpartial-availability]
return [#"foo" containsString:#"bar"];
^
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk/System/Library/Frameworks/Foundation.framework/Headers/NSString.h:132:1: note:
'containsString:' has been explicitly marked partial here
- (BOOL)containsString:(NSString *)str NS_AVAILABLE(10_10, 8_0);
^
foo.m:5:20: note: explicitly redeclare 'containsString:' to silence this warning
return [#"foo" containsString:#"bar"];
^
1 warning generated.
see also: Is there a way for XCode to warn about new API calls?
I check my code by hacking around Availability.h to get the compiler to flag weak-linked symbols as warnings/errors. In my current (Xcode 5/llvm) incarnation, I'm using the code below. It warns whenever I use a symbol introduced in iOS 6.0 or later. I think it's fairly self-explanatory. The macros seem to need updating at each and every SDK update, so tread carefully. Oh, and you loose deprecation warnings too, so I only use this once in a while to double-check my conditional code.
#undef __NSi_6_0
#define __NSi_6_0 deprecated=1.0
#undef __NSi_6_1
#define __NSi_6_1 deprecated=1.0
#undef __NSi_7_0
#define __NSi_7_0 deprecated=1.0
#undef __NSd_6_0
#define __NSd_6_0
#undef __NSd_6_1
#define __NSd_6_1
#undef __NSd_7_0
#define __NSd_7_0
See also http://iphone.m20.nl/wp/2013/10/xcode-5-and-flagging-weak-linked-unavailable-symbols-from-a-newer-sdk/
Since Xcode 9 there is a build setting doing exactly this, turning on the warning -Wunguarded-availability and/or -Wunguarded-availability-new.
The former warns when an API newer than the deployment target is used. The latter only warns when an API introduced newer than macOS 10.13 or iOS 11 is used in a similar manner.
For an existing project, the former is off by default, and the latter is on by default.
This setting is called “unguarded availability” within Xcode’s build settings pane, and you can choose one of Yes, Yes for all versions, or No from the GUI.
For more details, see the WWDC17 session 411, “What's New in LLVM”, https://developer.apple.com/videos/play/wwdc2017/411/ .
Problem
Instruments' Time Profiler is stripping all symbols except system libraries from my app, despite the fact that I have disabled this behavior in all relevant build settings in Xcode — but only on one development machine. The other dev machine behaves normally.
Description
Instruments' Time Profiler is stripping all symbols except system libraries, despite the fact that I have disabled this behavior in all relevant build settings in Xcode — but this is only happening on one of my development machines. I have two development machines running the same version of OS X, Xcode, and Instruments, and each machine is using an identical copy of the same Xcode project with identical build settings, schemes, and other configurations, and the app is profiled using the same test device (iPhone 4S with the latest public version of iOS 5).
Machine 1
- Mac OS X 10.7.4
- Xcode 4.3.2 (4E2002)
- Instruments 4.3 (4321)
Machine 2
- Mac OS X 10.7.4
- Xcode 4.3.2 (4E2002)
- Instruments 4.3 (4321)
Steps To Reproduce
Open included sample project on each machine.
Make sure the iPhone 4S is selected as the test device.
Select Product > Profile
When Instruments launches, select Time Profiler and continue.
Run the app.
Notice how the symbols are stripped when running on the iMac (Machine 1) but not on the MacBook Air (Machine 2).
Expected Behavior
Symbols from my own code should appear in the Time Profiler on both machines.
Regression
I have tried all of the following, with no change in the actual results:
Rebooting the machine.
Trying other Xcode projects
Deleting the "Derived Data" for all projects in the Xcode Organizer.
Re-symbolicating the document in Instruments (carefully selecting the correct DSYM file in ~/Library/blahBlahBlah…)
Final Notes
Here is a link to a .zip file of a sample project: Sample Project .zip
I was finally able to get it to work by a method that's just shy of a nuke-and-pave scenario:
Make absolutely sure all symbol stripping is disabled for your current build configuration. Make sure you've done this for your Release config if that's what's being profiled for Instruments.
Delete the app from the iOS device.
Restart the iOS device.
Restart the Mac (I don't trust Xcode or Lion at all to quit all relevant processes otherwise).
Launch Xcode, go to Organizer > Projects and delete Derived Data for the affected project.
Clean your project. Hell, why not?
Build and profile for Instruments.
Choose the Time Profiler in Instruments for clarity.
The first run will not show the symbols, but don't quit. Leave Instruments running!
Re-symbolicate the document in Instruments, navigating carefully to the correct dSYM file for the current build. This should be easier since you've deleted the derived data in step 5.
Now you should be able to see your symbols. It helps if you hide non-objective-C symbols.
Why do I suggest that you delete the app and restart the iOS device in Steps 2 and 3? I have a suspicion that Xcode doesn't perform a clean installation of each build, but may install deltas, such that the symbol addresses present in Instruments are a mixture of the current build plus previous builds. If so, then this issue is even more common for someone like me, who shares a single test device between more than one Mac. This assumption could be wildly incorrect.
If the above steps don't work for you, please let me know in the comments. I'd like to create a detailed radar report at some point in the future.
I'm not sure that it has been fixed in the 4.3 but this is a known problem in 4.2 seen here
Instruments
There is a known issue with the Profile action from Xcode 4.2. After a build in which no source files have changed, Instruments will be unable to gather symbols for the target application.
This affects projects where both:
The Release configuration is selected for the Profile action.
(default)
The Strip Linked Product build setting is set to "Yes”, or
a custom Run Script build phase strips the product. (non-default)
The workaround is to do any one of the following:
Perform a "Clean" on the product before initiating the Profile
action.
Do a Clean of the product and temporarily set the Strip Linked
Product build setting to "No" while Profiling.
Set the configuration of the Profile action to Debug.
Run successive profiles directly from within Instruments when you do
not need to rebuild. When developing Mac apps, using the GC Monitor
template in Instruments may cause Instruments to crash. To
workaround the problem please consider migrating your application to
ARC.
I've had a similar problem for days. I was able to profile the Debug configuration, but not Release. First I tried to make a copy of the release configuration (as suggested somewhere on the web), but that copy did not work either.
Then I made a copy of Debug, called it Profile, tried it and the symbols of Profile were shown in the profiler. Great! I then changed the optimization levels etc. to the same as Release, and now it works! Just wanted to share this, as this comment would have spared me hours...
Have been facing the same and stumbled upon this thread.
I realized that I first profiled the app with release build and after changing the scheme in Xcode for the same app, the profiler was still unable to symbolize. I have tried all obvious solutions you mentioned above but in vain.
The profiler somehow is still referring to the first build (release build)'s settings and hence it is not able to symbolize. So, I just changed the app's bundle identifier for testing purpose so that a new app is created altogether for profiling purpose. I could check the code where leaks exist now.
Try it out and let me know if this works for you too. Still pondering over why Instruments is failing to symbolize though.
I had a similar issue where I had no symbols in my os x application that I built from the command line (so in this case it is not an iphone or xcode issue). It turned out the problem was due to a bad DYLD_LIBRARY_PATH that contained my PATH. When I got rid of all those non-library paths, such as /usr/bin/, it worked.
I have a lot of third party frameworks whose symbols and binaries are unfortunately getting lost.
Additionally, my app's binary was getting lost.
I.e. if I selected File > Symbols, clicked my target, and found the similarly named item, the Binary Path was showing up red.
The solution was to go to Instruments > Preferences > Symbols, and add /Users/<MY_USER>/Library/Developer/Xcode/DerviedData to the search paths. Library is not indexed by Spotlight. After doing this, I have at least had the symbols for my app. The little circle next to my app's name goes from Yellow to Green when I do this, and persists between restarting Instruments, unlike other solutions to manually set the binary.
Let me know if you can tell me how to get all the ones for my third party frameworks. I use Carthage for some, others installed manually. Have had no luck with these yet.
I've managed to solve this by:
Disconnecting the device
Deleting the iOS Device Support files for the device's version of iOS in ~/Library/Developer/Xcode/iOS Device Support
Reconnecting the device and letting Xcode reinstall device support.
To be safe I first quit Xcode and Instruments, deleted derived data, and did a clean build as mentioned above, but no need to delete the app or restart any devices this way.
Try open XCode 3 and him Organizer. And try add from this Organizer a devices to both machines.
Just open Organizer and wait him processes. If you're see a button "Use for development" then click him.
Sometimes, XCode 4 can't add a device a truely for full development.
When I look at my schemes in xcode 4 after I connect my iPad, I see two schemes listed for my device (one to the right of my project name in the drop down list, and one right underneath it). I don't see any discernible difference in the schemes when I select Edit Scheme, but when I try to build the topmost one, I always get errors such as:
Cannot find protocol declaration for 'NSXMLParserDelegate'
Does anyone know why there are two device schemes or why the topmost one gets errors like the above one (but not the second one)?
I had the same problem. I found two SDKs in my Xcode.app:
/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/
iPhoneOS4.3.sdk
iPhoneOS5.1.sdk
I delete an old SDK iPhoneOS4.3.sdk, now everything is ok.
These device entries were actually labelled in some previous versions of Xcode as -
(your device) overriding base SDK to iOS (device iOS version)
(your device) with project settings
Xcode is displaying a device scheme for each of the iOS SDKs you have on your system.
If you want to remove those duplicate devices, you can either delete or move old SDK versions out of the system folder they reside in -
MACHD/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/...
Delete or transfer the old SDKs and relaunch Xcode to notice the updated device schemes. I'm not sure if you really want to be removing those SDKs... but that will get rid of those extra duplicate devices.
I had the same problem with an Xcode3 project when I upgraded it to Xcode4. I would have 5 "device" entries appear for each device I connected, but only the bottom-most one in the list would actually build successfully. I couldn't find any combination of settings that would resolve it, so I exported the scheme (which looked fine), deleted it, and let Xcode generate a new one. It's working fine now, so it must be some issue in the migration path.
I had the same problem (iPhone showing up twice when connected). What did work for me was: uninstalling all dev tools using
"sudo /Developer/Library/uninstall-devtools –mode=all"
Then reinstall XCode. Be careful though, the App Store will say, that XCode is already installed, so I ran the "Install Xcode" app in Applications.
Also see Why does Xcode create nonsensical destinations in every scheme?
The orginal question was posed on an Apple mailing list (http://lists.apple.com/archives/xcode-users/2011/May/msg00148.html), but the answer is easier to read from the above site.