Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Small update to iOS compilation docs #2212

Merged
merged 2 commits into from
Mar 1, 2019
Merged

Small update to iOS compilation docs #2212

Changes from 1 commit
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
304e307
Small update to iOS compilation docs
Feb 25, 2019
2812d51
Proofreading
akien-mga Mar 1, 2019
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
15 changes: 11 additions & 4 deletions development/compiling/compiling_for_ios.rst
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -10,7 +10,7 @@ Requirements

- SCons (you can get it from macports, you should be able to run
``scons`` in a terminal when installed)
- Xcode with the iOS SDK and the command line tools.
- Xcode 10.0 (or later) with the iOS (10.0) SDK and the command line tools.

.. seealso:: For a general overview of SCons usage for Godot, see
:ref:`doc_introduction_to_the_buildsystem`.
Expand Down Expand Up @@ -47,9 +47,16 @@ It can be done in three steps, first compile 32 bit version, then compile 64 bit

::

$ scons p=iphone tools=no bits=32 target=release arch=arm
$ scons p=iphone tools=no bits=64 target=release arch=arm64
$ lipo -create bin/godot.iphone.opt.32 bin/godot.iphone.opt.64 -output bin/godot.iphone.opt.universal
$ scons p=iphone tools=no target=release arch=arm32
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

arm was correct, arm32 is a working alias, but the actual string testing against in detect.py (beyond this alias matching) is arm. Could be renamed to armv7 to match what is passed to the compiler, but that's another topic :)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I figured the alias could preserve the clarity of 64 bit vs 32 bit while dropping the verbosity of bits=. I don't believe Apple has release a v7 device since ~2013 so we maybe we want to consider only supporting 64 bit moving forward?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

bits was unnecessary in the previous example, simply arch=arm is armv7.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

And yeah, in the future we could drop armv7 support, but not for 3.1. You'd be surprised at how much some users want to support old devices (often because that's the ones they have themselves to do tests on).

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

64 bit is iPhone 5s and newer. The iPhone 5c was the last 32 bit handheld device from Apple.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Definitely do not want to rock the 3.1 boat 👍

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

100% agree, drop 32bit, Apple demands us to compile with the latest XCode anyway if you want to publish on the AppStore. Pretty sure the next major release of XCode won't even support compiling 32bit iOS anymore. It's a dead horse.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

(3.2+, leave 3.1 as is :) )

$ scons p=iphone tools=no target=release arch=arm64
$ lipo bin/libgodot.iphone.opt.arm32.a bin/libgodot.iphone.opt.arm64.a -output bin/godot.iphone.opt.universal.a
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As per the above, the binaries won't have arm32 extension a priori (if they do, it's a bug).

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Doh! Copy and paste error.

$ ls bin
libgodot.iphone.debug.arm64.a     
libgodot.iphone.opt.arm64.a
godot.osx.opt.tools.64            
libgodot.iphone.debug.fat.a       
libgodot.iphone.opt.debug.arm64.a
libgodot.iphone.debug.arm.a       
libgodot.iphone.opt.arm.a         
libgodot.iphone.opt.x86_64.a


If you also want to provide a simulator build (reduces the chance of any linker errors with dependencies), you'll need to build and lipo the ``x86_64`` architecture as well.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've seen reports from users that they also need an x86 build to run the simulator matching their armv7 build, is this correct? We currently build all four architectures for official binaries.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If I understand correctly, you're asking whether you need to provide a desktop 32 bit slice for simulator compatibility? I believe 100% of Apple hardware (MacBook and iMac) devices that users would be using have been 64 bit (and thus x86_64) since ~2011 or so.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

See microsoft/cpprestsdk#1015

Copy link
Contributor Author

@samgreen samgreen Feb 25, 2019 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thinking about this more, I think the flag we provided historically to support 32 bit intel mac was i386. But that was maybe 5-6 years ago.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

that timing...haha

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Xcode 9.4 was the last version to support i386 compilation. I can build armv7 slices with Xcode 10 and run them on the simulator, without even the capability of building i386.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@mobileben Thanks for the reply. Do you have any info about your environment? Just trying to figure out where the disconnect is coming from in my reasoning.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I just attempted adding the build setting for i386 in a new project and received this:

The i386 architecture is deprecated. You should update your ARCHS build setting to remove the i386 architecture.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It looks like the SDK slices (or at least the i386 slice) shipped in the 10.14 SDK are no longer multi-arch and only contain x86_64 sections. This confirms my previous findings via lipo.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@samgreen I'm using Xcode 10.1. And my min deployment target is 10.0.

32-bit devices are iPhone 5, 5c, and iPad (Oct 2012). So if I build for an iPhone 5 simulator build, at least on my system it most certainly builds with i386

Example snippet

/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang -x objective-c++ -arch i386 -fmessage-length=0 -fdiagnostics-show-note-include-stack -fmacro-backtrace-limit=0 -std=c++14 -stdlib=libc++ -fobjc-arc -fmodules

Moreover, if I lipo the resulting binary

racerx:ben:JKS.app $ lipo -info JKS
Non-fat file: JKS is architecture: i386

And if I also go one step further and go into the ~/Library/Developer/CoreSimulator/Devices location to where the device (simulator) is, it also yields that it is i386 arch (same results as above).

And as an FYI, at least for me I ran into this for a couple of reasons.

  1. I like to build for different devices (even if it is the simulator as I don't own every device out there)) in order to verify things. In particular, my game works with a backend that vends properly sized assets. It does not use the model info (I use systemctlbyname), rather it uses native bounds values and then computes the best size from there. So I like to ensure that the different devices all work.
  2. I do also run on the simulator different configurations. As you can see from my settings not all of them only build the valid arch. Some build all. And in that case, I hit the i386 issue with cpprestsdk.

I do realize i386 is deprecated and I expect Apple at some point of time to completely remove it. I have a feeling the first step is to further hide the existence of it within Xcode. Realistically ... unless they plan on re-writing how they do things which is doubtful based on it being Apple ... they will need to back support this (32-bit slices) until people no longer support lower iOS SDKs (10 or earlier).

I'm showing my build settings related to Architectures. More or less I use the default except for building active architecture.

screen shot 2019-02-25 at 9 26 56 pm

When you say you can build for armv7 simulator build, are you positive it really isn't building with i386? From my understanding, this is how Xcode works. It implicitly builds with i386 for 32-bit slices. It builds with x86_64 for 64-bit slices. Or rather this is what I reason it is doing based on observation.

I was the one that added back the i386 slice to cpprestsdk because they upgraded the iOS build process and then it broke me. I had previously provided another method that took into account 32-bit slices but adjusted the build to accommodate the update. By default, it shouldn't include the 32-bit slices.

My build invocation for cpprestsdk is:

./configure.sh -deployment_target 10.0 -include_32bit -no_bitcode -config_only -clean

Hope this helps?

::
$ scons p=iphone tools=no target=release arch=arm32
$ scons p=iphone tools=no target=release arch=arm64
$ scons p=iphone tools=no target=release arch=x86_64
$ lipo -create bin/libgodot.iphone.opt.arm32.a bin/libgodot.iphone.opt.arm64.a bin/libgodot.iphone.opt.x86_64.a -output bin/godot.iphone.opt.universal.simulator.a


Run
Expand Down