Setting up an iOS cross-compiler (hosted on macOS) #34
Comments
|
there's some old statement about "walking before running" ;-) There are a number of things we never implemented in GCC because we had no iPhoneOS/iOS/tvOS/watchOS support - e.g. min versions etc. My guess is that those will affect the way in which SDK headers get used. Probably not rocket science to add what's needed (but we'll have to add the validation of xxOS versions in place of that used for macOS). (conjecture) [when starting on the Arm64 port] I went through an exercise of comparing what the clang driver produced in response to various permutations of --xxxxx-version-min, archxxx, etc. .. and it's somewhat complex .. it's likely that the code-gen is not too much wrong but the configury and packaging will need working through... |
|
of course, we have no support for Arm iPhoneOS at all (no Mach-O backend stuff for the Arm port) - so you would have to ensure that the configury did not try to do that. |
|
@iains what would be the best way, in your opinion, for GCC to make a difference between iOS and macOS on ARM, both being I know “walk before you run”, but to be honest I think for some limited use cases, we're not far from having a Fortran compiler for iOS, which is something people have been asking for a really long time. It would enable things like scipy and other scientific software. The limited use case could be “generating object files and static libraries” to link in a bigger project, for example. |
|
(long[er] term) That is somewhat confusing - actually, IIRC, clang uses -target xxxxx-apple-darwin == iOS and xxxxx-apple-macos[x]NN.MM == MacOS .. and then some things extra for tvOS and watchOS .. I'd need to run through the exercise again. It's a plan to get the darwin port to recognise "-target" and try to harmonise at least the user-facing command line options with those of clang. === I think that if we can let the backend know we're targeting iOS, probably we don't need to do too much heavy lifting.
My concern is the the backend is experimental and has known issues; you understand that, I understand that - but once published for end users , be prepared for complaints that "it don't work". |
|
sigh if only all the end users cared enough to fund at least one full-time Darwin engineer .. that would still be hardly enough .. but at least a step in the right direction (the Linux distros have a team of toolchain engineers, after all). |
|
@iains I know I've been trying to figure out ways we could get funding to improve the state of things… don't know good ways, it seems some open source is now funded through foundations (like Gates for some machine learning toolkits, etc) |
In clang, |
|
In my experience |
|
there are two places that count ;
GCC also has a driver (that's what you get when you type We have not, so far, implemented the equivalent checks and balances for iOS. So I'd say "all bets are probably off" about how the SDK headers are interpreted and values passed to the assembler / linker. You might be lucky - but I expect that currently we're lying to both the assembler and linker (claiming to be macOS when you really wanted iOS). |
|
An update of progress by myself, I have successfully been able to compile gmp, mpc, mpfr for iOS and made sure they work. I've also done most of the other gcc dependencies including binutils |
|
I am building on linux, so things may be a little different: What is bizarre is that configure does not respect the host of the initial configuration (which was aarch64-apple-darwin) rather, it sees the host as the build system Edit: manually going to the Build folder and rerunning make works |
|
fxcoudert
changed the title
|
@demhademha the procedure discussed here only works for a macOS host machine, because it's using the multi-arch Apple compiler/assembler/linker. |
|
Thank you for the work so far. How did you get the cross-compiler to actually target iOS after it is compiled? Is there some flag to specify that I am building for iOS? I am currently just using "-arch arm64", as gfortran does not seem to support "-target". |
|
You need both As @fxcoudert said, the command line to compile is a bit large: |
|
Just a note: There's also iPhone Simulator, Watch Simulator, Apple TV Simulator, Mac Catalyst, DriverKit as well as bridgeOS targets. From ld(1) on iOS |
|
|
|
Note that for the 64-bit version watchOS have 32-bit pointers on a 64-bit CPU (much like x32 in this regard), and is called arm64_32, which is a different ABI. |
|
I'm trying to follow the instructions in the OP on macOS Monterey x86 but it fails at libgcc_s.dylib: libgcc_s.dylib errorThe only difference from OP is that I added Any ideas? EDIT: |
…ctions When gcc is built with -mbranch-protection=standard, running sanitized programs doesn't work properly on bti enabled kernels. This has been fixed upstream with llvm/llvm-project#84061 The following patch cherry picks that from upstream. For trunk we should eventually do a full merge from upstream, but I'm hoping they will first fix up the _BitInt libubsan support mess. 2024-09-05 Jakub Jelinek <[email protected]> * sanitizer_common/sanitizer_asm.h: Cherry-pick llvm-project revision 1c792d24e0a228ad49cc004a1c26bbd7cd87f030. * interception/interception.h: Likewise.
I am documenting here my notes on how to use this branch to set up a cross-compiler to aarch64-apple-darwin (ideally iOS, not macOS) from x86_64-apple-darwin. I hope you don't mind Iain :) The goal is actually to produce an iOS cross-compiler.
I managed to get something working with:
Some notes on this:
buildand nothost, as GCC otherwise thinks it's setting up a Canadian cross (which fails)sysrootfor iOS is theiPhoneOS.sdkSDK (weird name…)*_FOR_TARGETare important, as they are not automatically detected by gcc*_FOR_TARGETneed to have an absolute path, otherwise the configure script will discard them (I don't fully understand why, and this cause a lot of pain to figure out)--disable-multilibwould be needed, but without it, GCC tries to build two variants ofaarch64-apple-darwin20: a normal one and alp64one. This feels like a bug, really.What is the result? Well, the compiler builds and most of the runtime libraries do, as well.
ldwarning:I'm not sure where in GCC we're creating macOS-specific code, but it may be from passing the linker the
-mmacosx-version-min=option in various places.libgfortranfails to build withimplicit declaration of function ‘getentropy’, because on the iOS SDK,getentropyexists (thus configure finds it in the system libraries) but it's not declared (and you're not supposed to use it, it's considered a private API). If I bypass this, the build succeeds.libsspfails (not that I care much) with2023 edit:
DSYMUTIL_FOR_TARGET=/usr/bin/dsymutilis also needed now.The text was updated successfully, but these errors were encountered: