Are the macho headers located in /usr/lib/mach-o backward compatible to executables over different iOS versions 4,5,6 etc? If so, where can I get the specific versions of them. I tried searching on the Apple Darwin site but they don't maintain them as a separate project.
The header files are compatible, but the Mach-O files as of iOS 6 are not compatible, having replaced the LC_UNIXTHREAD load command with an LC_MAIN (as well as adding a few other load commands which are unrecognized by otool and friends in previous versions of the OS). This also applies for Mountain Lion binaries, which for the same reason cannot be executed on Lion or earlier.
Related
I have updated mac to 11.6 and xcode to 13.0. Realm could not compile so I updated it with carthage to v10.15.1. Now I get this runtime error just after the app launch:
Library not loaded: #rpath/Realm.framework/Realm
Referenced from: /Users/username/Library/Developer/Xcode/DerivedData/appname/Build/Products/Debug-iphonesimulator/RealmSwift.framework/RealmSwift
Reason: tried: '/Users/username/Library/Developer/Xcode/DerivedData/appname/Build/Products/Debug-iphonesimulator/Realm.framework/Realm' (file does not start with MH_MAGIC[_64], file does not start with MH_MAGIC[_64], fat file, but missing compatible architecture (have 'x86_64,i386', need 'x86_64')), '/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Library/Developer/CoreSimulator/Profiles/Runtimes/iOS.simruntime/Contents/Resources/RuntimeRoot/usr/lib/swift/Realm.framework/Realm' (no such file), '/usr/lib/swift/Realm.framework/Realm' (no such file), '/Users/username/Library/Developer/CoreSimulator/Devices/33E61712-D8A9-4D7E-A260-5C096BE08A82/data/Containers/Bundle/Application/AC700919-F431-446F-8BEF-FF8D8E5F5BF9/appname.a
I guess the key part here is file does not start with MH_MAGIC[_64], but I could not find anything useful about the error.
I tried embedding the library and turning off the embedding, does not affect anything.
Realm has 3 targets configured to be built with Carthage (Realm, Realm iOS Static and RealmSwift)
XCode 13 deprecated a setting for building targets in a manually set order which leads the first 2 targets to be built in a non deterministic order (the 3rd one is always last as it depends on the 1st one). The order and the frequency of it changing seems to be random (it might depend on the specific XCode version)
When 'Realm' is build before 'Realm iOS Static', the fat framework replaces the one in the xcframework which leads to that error. In the other case, it's the correct one that's built second and overrides the wrong one.
I guess the solution (apart from upgrading Realm) would be to remove the target 'Realm iOS Static' from the project but it's not straightforward to do with Carthage except by forking Realm
The latest version of realm is v10.32.0. xcode 14.1 is also out.
You need to update your toolset.
The latest upgrade realm version 10.32.0 is compatible with XCode 13.1 and above. If you use the legacy build system, migrate it to the latest one and clean the derivable folder before rebuilding the code. Most of the time derivable keeps track of the older version files and makes conflicts once you update the project tools. Hope this will help
Does anyone know how to publish a .NET Core 3.0 application for ARM64?
I can only select "linux-arm" but no "linux-arm64".
Setting linux-arm in combination with x64 also doesnt work. It says the settings are not compatible.
As stated here it should already be supported: https://github.com/dotnet/core/blob/master/release-notes/3.0/3.0-supported-os.md
The linked article points to the supported OSs, not the list of runtime identifiers. An explanation of an RID and a list of common ones can be found in .NET Core RID Catalog. The full list can be found at the CoreFX repo, in runtime.json. linux-arm64 is included but that's only the base OS. There are a lot of specific identifiers like "debian-arm64", "debian.10-arm64", "rhel-arm64" and "ubuntu-arm64". You'll have to use the RID that corresponds to your distribution.
As the RID catalog explains, a runtime identifier consists of the OS, OS version, architecture and optional extra qualifiers.
[os].[version]-[architecture]-[additional qualifiers]
ubuntu-arm64 is the generic Ubuntu version for ARM64 while ubuntu.19.04-arm64 targets Ubuntu 19.04 specifically.
There's no specific version for Raspbian. If you want to target Raspberry in general, you'll have to use linux-arm. If you want to take advantage of the 4GB RAM model, assuming you already use a 64bit OS you may be able to target linux-arm64.
The linux-arm64 isn't available from the publish profile settings, but if you build it using linux-arm and manually edit your .pubxml file afterwards, it works on the pi just fine. As the link you provided shows, it is supported. It seems it hasn't been added to the tooling yet.
Just publish as usual and then edit .pubxml
Change
<RuntimeIdentifier>linux-arm</RuntimeIdentifier>
to
<RuntimeIdentifier>linux-arm64</RuntimeIdentifier>
Then you can publish on a 64bit Raspberry pi.
Having some issues with the online installers, I would like to use the offline installers to create an installation with multiple Kits and versions. I would like to be able to switch between MinGW, Visual Studio and mobile targets just by switching between the Kits, and I would like to have the latest two Qt versions (5.4 and 5.5) available for choosing.
However, there are some issues with this:
The offline installers are only available with a single Kit. Installing the same version twice with different Kits to the same directory seems to mix up Qt Creator's available Kits, and the installation seems to replace the previous one in Windows' list of installed software.
Every single setup comes with its own Qt creator instance, and only there the Kits are available as desired. So when installing in seperate directories, a lot of duplicate stuff is installed.
I tried copying together kits from a few installations, but running a big installation, copying part of it and then patching the kit with the installer again seems to be a bit weird ...
Isn't there an easier way to get a consistent installation on Windows with the offline installers?
First of all, I believe this issue is not as big as I thought: Even the multiple Qt Creator installations that come with every offline installer do not create any bigger conflicts. The only thing that might happen with these: When starting different versions of Creator after each other, one might see conflicts with the settings files of QtCreator which are always stored in %APPDATA%/QtProject: Using an older version can corrupt the newer one.
That said, I believe the simplest way to work with different Qt Versions is to use a new installation folder for every Qt version, and to use a separate installation of QtCreator. Then one of course has to set up debuggers, Qt Versions and Kits manually for each new installation. The benefit of this is that one can also simply remove any version one doesn't need anymore - without risking to remove the used Qt Creator.
Qt creator automatically seems to detect and select appropriate help files + examples from the installed Qt versions.
Compared to using the online installer, the installation needs more space for the multiple Qt Creators, however installations are really separate from each other, so there is no risk in messing up anything by using the online installers again when a new version comes: the online installer only gives the latest two major versions with their latest minor version, and when changing from one minor version to another, one might want to compare results between these.
Can I create code on Xcode4 and then run this exact same code on Xcode3. In other words is it backward compatible and if not what do I have to do to ensure that I can run the code on xcode 3.
Not something I've tried. You need to check the Project Format is set to the matching Xcode 3 version. But I would still not be surprised if it didn't work. The reality is that this is Xcode's way of telling you to update your XCode 3 machine :-)
BTW, you will probably also run into a number of SDK version issues as well.
Yes, you can run the same code in XCode 3 assuming you haven't used features available in newer SDKs, not available in older XCode version.
But as #drekka said, project format will be most likely incompatible between two versions, so you'll probably need to ignore XCode 4 project upgrade warnings.
I'm developing an app which is iOS 4 compatible, so my deployment target is set to iOS 4.0.
Whenever I drop a UINavigationController onto a UITabBar, I get these two warnings:
warning: Attribute Unavailable: Defines Presentation Context is not available prior to Xcode 4.2.
warning: Attribute Unavailable: Defines Presentation Context on iOS versions prior to 5.0.
The UINavigationController functions as expected, in fact, the entire app runs perfectly. But these two warnings are driving me nuts!
Also, the moment I delete the UINavigationController the warnings disappear.
Just uncheck the "Defines Context" checkbox in the attributes inspector. (Double-click on MainWindow.xib, select the navigation controller, then go to View->Utilities->Attributes Inspector.) That'll get rid of the warnings.
You are getting these warnings because you are using iOS 5.0 SDK features with a 4.x deployment target.
All, if not, most of the new 5.0 hotness, including ARC and Storyboards, is completely backwards compatible with iOS 4.x (I don't remember if 4.0 or 4.3 is the lowest supported version, check the docs), it will work as intended, but Xcode is going to warn you anyways.
You should be able to disable that warning if it really bothers you, but I wouldn't. That said, Apple does not currently accept applications built/archived with the Xcode 4.2 beta for submission to the App Store. This means you need to use Xcode 4.0/4.1 in a production environment.
Before we go any further, you should know that Xcode 4.2/iOS 5 is beta software, it is under NDA (you agreed to this when you joined the Apple developer program) and cannot be discussed in the public domain. This means you won't be able get much help from places in the public eye, like StackOverflow, as good as it can be. But, since I'm here and this is a very high level question, I can help :)
In the future, if you have iOS beta questions or issues, you should hit up the Apple Developer Beta Forums (an excellent resource, always search before you post), or #iphonedev on irc.freenode.net for not-beta stuff (I'll be there, say hi!)
If you're developing an application for release on the App Store:
You need to be developing with Xcode 4.0 or 4.1, Apple will not accept applications built/archived with 4.2. (I know I repeated myself, but people seem to miss this often)
And, although 4.2b7 supports developing for older frameworks better than previous Xcode betas have (by allowing you to install previous versions of the simulator), you will still find yourself accidentally using 5.0 SDK functions all over the place, as the code completion/interface builder very aggressively favors all of the new hotness. This is because the beta is for trying new things, not stable application development.
This means you need to switch back to using Xcode 4.0/4.1 for production, if you don't have it installed, or you overwrote the stable version with the beta, do not try to install 4.0/4.1 on top of the 4.2 beta, weird things will happen and both versions will start acting really weird and and Xcode will crash at least twice as often.
The best thing to do in this situation, is to follow the below steps. Make sure you don't skip anything, otherwise you'll have to restart the whole process.
Make sure you have your code committed and pushed up,
uninstalling Xcode like this temporarily removes git. (This was an
issue for me at work once)
Download the installers for Xcode 4.0/.1, and 4.2 if you intend to keep experimenting. (if you already
have both downloaded, this whole process won't take more than 5
minutes on an SSD)
Uninstall the Xcode beta from the command line using this command:
sudo <Xcode>/Library/uninstall-devtools --mode=all (more info here)
Restart your computer (this is important, do not skip it!!!)
Install the most recent non-beta version of Xcode and resume development.
If you want to use both versions of Xcode (4.0/4.1 and 4.2):
You must install the beta AFTER 4.0/4.1 is installed, otherwise you will be overwriting new things with old things, and this will give you many, many obscure headaches. I also recommend restarting between installations.
You need to install 4.2 after 4.0/4.1, and to a different folder (I use /Xcode4beta/, don't put it within the folder that contains 4.0/4.1, either). I've found I learn about the new hotness best if I keep separate iOS5 branches of my work, and update what I can when I have some free time.
If you have the iOS5 beta installed on your phone, and Xcode 4.0/4.1 won't let you build to your phone:
This is because Xcode needs to grab the debug symbols from the phone before it can be used for devleopment, but only the Xcode beta can do this for an iOS5 beta device, so follow these steps:
Make sure your phone is plugged in and turned on, and that your provisioning profile/certificates all check out.
Close the project in Xcode 4.0/4.1.
Open the project back up in Xcode 4.2, and check organizer. You should either already have a green dot next to your phone (assuming all of your provisioning is working), or it should be gathering the debug symbols. Let this finish, and then build your project. It doesn't need to be a successful build, nor do you have to install the application to the phone, sometimes you don't even need to build, Xcode can be a fickle mistress.
Close the project in Xcode 4.2.
Open the project back up in Xcode 4.0, you should now be able to build and install to your phone as you normally would.
Xcode 4.0/4.1 should now be able to use your device for development until you restart the computer.
Resolution is here:
How can I fix "Freeform Size simulated metrics are not available prior to Xcode 4.2" warnings?
You just need to change the development version of your xib file to Xcode 4.2 (default is Xcode 4.1)
View Controller and Navigation Controller setting or options name ( attributes inspector )
Define Context ( Checked ) unchecked.