OK, putting aside the obvious packaging and signing issues, would it be possible to compile IOS/iPhone compatible executables, by using correctly constructed LLVM bitcode (IR) from a non-Apple operating system, such as Linux or Windows, i.e. by utilising some combination of Open Source compiler infrastructure such as LLVM, Clang or GCC?
Basically, what I'm contemplating is
Compile a pre-existing cross-platform SDK (IOS-compatible) to LLVM Intermediate Representation (IR/bitcode).
Analyse and identify the IOS-specific LLVM (IR) function calls within this layer, using LLVM analysis tools.
After the compilation of the SDK to LLVM IR on the non-Apple system, replace the Apple/IOS-generated-LLVM-bitcode-SDK-representation within the corresponding LLVM IR function calls generated by the non-Mac host.
[possibly] employ the build flags emitted by the Mac's XCode/Clang/LLVM infrastructure, in order to build the IOS-compatible executable on the non-Apple host compilation machine (e.g. Linux or Windows).
If this is at all feasible, I would later investigate the creation of an iPhone/IOS bundle (the construction of IPA is documented, ask Google) and use the open-source Apple code-signing routines, already in use within other cross-platform IOS SDK's
RoboVM doesn't support cross-compiling iOS apps from OSes other than Mac OS yet but we plan on supporting that in the future. Here's an iOS cross-compilation toolchain which runs on Linux that may be of interest to you: https://code.google.com/p/ios-toolchain-based-on-clang-for-linux/.
Looks like Java-to-IOS is being taken care of by the RoboVM project:
Java to Native
The RoboVM compiler translates Java bytecode into native ARM or x86
code. Apps run directly on the CPU. No interpreter or virtual machine
involved.
It makes use of LLVM, as my question suggested.
Also of note is the Avian JVM project. It to can be used to compile to native and IOS binaries (by bundling the JVM), however, I'm uncertain as to the status or completeness of its user interface (UI) layer(s).
Both project appear to be in current and constant development.
Related
I am trying to build an AR app with ARKit, trying to run these open-source ARKit project and Plugins on github:
https://github.com/augmentedrealityplugin/shapeDetection
https://github.com/ShawnMa16/AR-Drawing
However I have this problem
I have tried the solutions:
Set 'Yes' in Build Libraries for Distribution
installing the Xcode Toolchain
delete and add the framework again in Embedded Frameworks
But it cannot help, is there any solutions to my problem, so I can at least try and run these project and Plugins on GitHub?
Swift obtained ABI compatibility in v5.0. But only gained module compatibility in v5.1. So, frameworks compiled with a version before 5.1 are toolchain specific. This is what what the compatibility error you’re receiving refers to.
Pre 5.1, you need to compile both your application and the library with the same version of the Swift compiler. With 5.1 and beyond, preferably, use the latest toolchain for both, but that is optional as long as they are at least compiled with 5.1 or greater. Existing binary distributions of the library compiled pre v5.1 will not work with the latest version of Xcode.
This means you’ll need to compile the library from source, upgrading the Xcode project settings to at least 5.1, and possibly the source code, as necessary.
See this post for more details: https://swift.org/blog/abi-stability-and-more/
I'm building my command line app, and noticed that all the binaries I create are of type arm64.
However, all the bins that ship with macOS 11.4 are arm64e.
i.e. running file on my app built on an M1 MacBook shows:
Mach-O 64-bit executable arm64
Whereas, running file on the system xxd app on the same machine shows:
Mach-O 64-bit executable arm64e
I've looked in Xcode and cannot see how to augment this, should Xcode not be building arm64e? If so how can I achieve the same?
Here's a picture:
EDIT: I think the answer might be, the arm64e ABI is unstable and not in use for anyone but Apple?
The main difference between targeting arm64 and arm64e is ARMv8.3's Pointer Authentication Codes. Since the specific ABI hasn't stabilized, Apple is only using it for their own platform code since they can easily recompile the entire OS version with a different ABI by shipping a new OS whereas they can't really force all developers to start using a new ABI.
Despite this, you can compile for arm64e simply by choosing "other..." on the architectures drop down and typing in arm64e. By default, macOS will refuse to run any non-Apple code that has the arm64e slice (since they want to prevent anyone from shipping arm64e code before the ABI is stable). You can, however, override this behavior and allow macOS to run non-Apple arm64e code by setting the arm64e_preview_abi bootarg:
sudo nvram boot-args=-arm64e_preview_abi
Note that you will need to disable system integrity protection to do so. This bootarg is meant to allow developers to prepare their software to run with pointer authentication enabled and really not much else.
I try to follow this guide:
http://code.google.com/p/iphone-dev/wiki/Building
it wants me to build LLVM from source, but I already have one installed in Ubuntu using apt-get, why they want me to compile from source? can I use the one provided by Ubuntu community? if not, how will they coexist? should I uninstall apt-installed llvm first?
The guide you're looking at is several years out of date, and will most likely not work. (In fact, there are a ton of frustrated comments suggesting that it hasn't worked since at least 2011, as the Mac OS X 10.4u SDK is no longer available for download.)
The only supported platform for iOS development is Mac OS X. I would strongly recommend that you use that platform if you want to do iOS development, as basically all tutorials you will find online will assume that's what you're using.
That all being said, if the instructions were otherwise correct, you would still need to build LLVM separately from the version provided by Ubuntu, as iOS devices use ARM CPUs, and the distribution's LLVM will only compile binaries for your system (probably either x86 or x86-64).
I'd like to use the excellent stringencoders library in an iOS application. It's a fairly typical c library, with a configure script generated by autoconf and a makefile.
What I'd like to do is compile arm7 and i386 versions on Mac OSX and then use lipo to make a fat binary.
I'm having trouble figuring out how to persuade the build tools to create my platform-specific binaries. There's a few articles out there and even a few scripts but most of them are targeted at XCode 4.2 and don't work with 4.3.
It looks like it should be possible to create a fairly generic build script that can play nicely with configure and make but I'm at a loss as to where to even start.
Have you successfully done anything like this? I'd love some pointers!
BTW: 'import all the sourcecode into your project' is NOT a viable solution. That way lies madness.
Thanks.
I've ported a handful of open source C libraries to iOS (see iOS Ports). I've found the most reliable way to port a library is to build a new Xcode project with a build target for a static iOS Library. It is important to note that Apple will not allow your iOS Application to contain dynamic libraries if you plan to distribute your app on the iTunes App store, so you will be unable to use FAT libraries.
These are the steps I usually follow when porting libraries to iOS which usually built with the GNU Autotools:
Run ./configure with appropriate flags on OS X.
Verify that the library builds correctly on OS X using make.
Create a new Xcode project using the iOS Static Library template.
Add the config.h from the previous configure run to the Xcode project.
Read the automake file (Makefile.am), and add the referenced sources in the automaker targets to the Xcode target for the static library.
Copy the CPP flags (i.e. -DHAVE_CONFIG_H) from the automake file to the build settings in Xcode.
Compile in Xcode and start running down errors (usually by adding missing header include paths or missing source files).
The directory structure I usually use is the following:
project/
project/ported-project.xcodeproj
project/project-x.x.x.tar.gz
project/project-x.x.x
project/project -> project-x.x.x
I know this is not exactly what you asked for in your question, however it is rough outline of the steps I've used for years for porting libraries. The benefit of creating an actual Xcode to compile the ported library is that it makes it easier to integrate the library into multiple Xcode iOS applications.
If you need clarification or more detailed instructions, let me know and I"ll try to write up more extensive instructions and update my answer.
Is it plausible to add the source files (i.e. .c files) to your project directly?
Objective C is a superset of C so i am surprised that the code did not work directly out of the box in XCode 4. Are you missing out something there ? just suggesting
Generate your project files using gyp: http://code.google.com/p/gyp/
I use it to share libraries between win/osx/ios and linux (pi).
I Have A project developed using XCode on MAC OS, for some special reason, I want copy entire project to the Linux operating system and go on developing on linux.
How can I develop and build it on Linux?
I am developing an I-Phone project, I using iOS libraries, I (wish to) develop and build on linux, run on iphone
No, it is not currently possible to build Native iOS applications using the native Cocoa Libraries and Objective-C on platforms other than Mac OS X.
You have two issues.
First, are you using OS X only libraries, for example Foundation or AppKit? You could potential develop a Cocoa program on OS X and build it against OpenStep on Linux, but at this point you would need to be very selective in which functionality you use, to the point where it is probably impossible.
Assuming that you have fully cross-platform code, then yes you can build it on Linux, but you will need to move away from the Xcode build system. You can create an Xcode project using an external build system, and then proceed to use something like scons, ccmake, or even make. That way the same build files with work both on OS X and Linux. Or you can continue to use the Xcode build system on OS X and keep a parallel build tool for use on Linux.