I have a 3rd party .a library, which is apparently compiled for only armv6 compatibility, where both new Xcodes (3.2.6 and 4), both now require a separate armv7 slice to run on the device. The link error is: file is universal but does not contain a(n) armv7 slice for architecture armv7.
Anyone know how to make either of the two new Xcode operate as 3.2.5 did and accept the existing library while I'm waiting for the library vendor to cook up an armv7 version?
Nothing worked for me until I set "Build Active Architecture Only" to No.
In Project Settings, select "Standard" for the architecture (not "Optimized"). This should allow you to select "armv6" for the Active Architecture. This means it should also work on older devices (barring any other deprecations) once it's on the app store.
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.
I'm developing a closed source application and to do so in accordance with the LGPL I have to dynamically link Qt's libraries to my application. Does Qt do this by default or do I have to take steps to do so? If that's the case how would I go about doing it?
Qt uses dynamic linking by default.
You'll notice this immediately during deployment to a non-developer machine, because your code will not run without the Qt libraries.
If your concern is the LGPL, just be careful when compiling Qt itself. Most LGPL violations with Qt are not because of static linking (since dynamic is the default), but for compiling Qt with non-default parameters.
LGPL is not just that the library must be provided along your binaries, but also that you specify how your users can build themselves the LGPL part. If you compile Qt yourself and do not use the pre-compiled binaries from the website, you must document that part of your build configuration in your release!
As soon as you get something running on your program, start preparing a release version for a non-developer environment without Qt installed. Your program should fail as soon as you delete the DLLs that you must copy along your program (or whatever format your OS uses).
It does it by default, statically linking seems to be quite involved judging by the many questions on the site regarding it.
I've updated the XCode to the latest 4 version (final). My project depends on a 3rd party library that was build for armv6.
The problem is that i can not change the "active architecture" as it was in 3.x.x instead I see that during linking the active architecture flag is always passed as armv7.
Does anyone know how to set active architecture for the build target (or for scheme) ?
Thanks in advance.
Answering to myself ...
Yes and no. You can not change the arc but you can trick the Xcode. Set it to compile not only for active architecture and leave only archv6 in the list. Hope it helps to whoever looks for an answer.
It is still possible to change the Architecure settings in Xcode 4. Select the project file in the Project Navigator. Then select the target you like to build. Then select build settings->All->Levels. In the search box enter "architectures". You should see the Architectures and Build Active Architecture settings.
I am using Qt in order to build a cross platform GUI app (Windows and Mac). I want to be able to update the app efficiently and automatically whenever there is a new patch available.
I saw this post which got me to take a look at WyBuild. It looks great and probably what I may end up using for the Windows version but what about Mac? What are some alternatives available to me?
I've just started developing a Qt-based autoupdater called Fervor for my own needs. You can try it out, contributions are more than welcome too.
For Mac the best choice is Sparkle used by WebKit, Adium, Cyberduck and more. Its only for Mac but I guess native look matters on Mac a lot.
Not familiar with WyBuild so cannot comment. Sparkle is a fine choice but the poster preferred a single app for both platforms. BitRock InstallBuilder contains an autoupdater written in Qt that can be used independently (disclaimer, I am the original BitRock developer). It is a commercial app, but we have free licenses for open source projects.
There is Updatenode which seems to provide a real Qt cross-platform solution.
It comes with a prebuilt client for Windows, Mac and Linux. The online service lets you manage updates very easy and are able to see good charts of your application usage.
And here another one of the possibilities:
Using the Qt Installer Framework: It provides installers for Windows/Linux/Mac with an build-in updater. If you need an example - The MaintenanceTool of your Qt-Installation uses the framework.
To get an auto-updater from it, all you need to do is:
Create an online installer (Just check the documentation, it's not that hard)
Use the maintenancetool in your application to check for updates.
This cane be done using my QtAutoUpdater. Go there for more information about the whole process
If new updates are available, the maintenancetool can be started in updater mode to install the update
Update the online repository - and your update is out.
Advantages:
Installer and updater in 1 tool - this means less work for you
Easy to use (with or without the QtAutoUpdater library)
Cross-Platform for all desktop platforms supported by Qt
The installer itself is a Qt original
Disadvantages:
No "native" installers (i.e. no .msi on windows or .deb on ubuntu)
Must be used together - if you want to use the update feature, you have to use the framework as installer
This may be obvious, but for Linux you can use the built in package manager. For example, apt-get, yum, pacman, or what have you.