How to Target Both arm64 and x86_64 for Mac Builds

[TyelorD]

In order to have the game playable on the widest possible array of Macs we have to target both arm64 (M1) and x86_64 (Intel) Mac architecture as well as target an older SDK version (10.15 is a good number for this, since it would be compatible with virtually all Macs still in use today).

It seemed that this should be possible by using axmol build -p osx -a 'arm64 x86_64' -minsdk 10.15 and indeed it nearly works. However during the linking stage of the build, the build fails with the following error messages:

ld: Undefined symbols:
  _png_do_expand_palette_rgb8_neon, referenced from:
      _png_do_read_transformations in libpng.a[arm64][9](pngrtran.o)
  _png_do_expand_palette_rgba8_neon, referenced from:
      _png_do_read_transformations in libpng.a[arm64][9](pngrtran.o)
  _png_init_filter_functions_neon, referenced from:
      _png_read_filter_row in libpng.a[arm64][10](pngrutil.o)
  _png_riffle_palette_neon, referenced from:
      _png_do_read_transformations in libpng.a[arm64][9](pngrtran.o)
clang: error: linker command failed with exit code 1 (use -v to see invocation)
note: Run script build phase 'Generate CMakeFiles/ZERO_CHECK' will be run during every build because the option to run the script phase "Based on dependency analysis" is unchecked. (in target 'ZERO_CHECK' from project 'AxmolBase')
** BUILD FAILED **

I haven't tried targeting just x86_64, however only targeting arm64 causes the build to succeed as normal.

Any help on this issue would be greatly appreciated, as we're currently porting our published game over from Cocos2d-x v3.17.2 to Axmol. So I'd like to be able to continue targeting all the same machine we currently are for our game.

[TyelorD]

osx combine archs is more complex, and we no plan to support it

Originally posted by @halx99 in #1791 (reply in thread)

This seems... bad? Most Macs still being used are using Intel chips, but new ones released are using M1 chips. But, as far as I'm aware, on the Apple App store you can only have one macOS build. So if you target arm64 architecture for your build, then no Macs with Intel chips can download and run your app on the Apple App Store, and like-wise if you target x86_64 architecture for your build, then no Macs with M1 chips can download and run your app on the Apple App Store.

This is especially concerting considering the fact that I was very quickly and easily able to get Cocos2d-x v3.17.2 building to macOS combined architecture. I had to recompile and lipo a couple of the pre-compiled libraries, but it didn't take long to do manually.

Should the build scripts for Axmol be able to automate the process that I did manually: i.e. make an arm64 static library and combine it with the x86_64 static library with lipo before linking the binary?

Edit: It appears that this is an issue with libpng right now, and has been for a while. The basic work around appears to be as I suggest. Build libpng for arm64, and then build it for x86_64, and then marge them together with a tool like lipo in order to create a universal library.

[TyelorD]

For anyone else who's curious I managed to do this with minimal work (though I'm not currently using Cmake to build or deploy, but instead Xcode, so your mileage will likely vary).

For me all I did was remove support for the astcenc library, which I didn't need anyways, and then setup libpng to be precompiled, since it can't currently be compiled to both architectures through a single build. Instead I build arm64, and then x86_64, and then create a fat library with both using lipo. I wrote a little shell script to automate this as well so that I can easily update libpng in the future if needed.

I have to admit though, it does disappoint me that this isn't supported out of the box. Is there really much of a reason libpng needs to be compiled at build time and not precompiled? I suppose one benefit is that we'll get debug symbols in libpng for Debug builds and RelWithDebInfo builds, but for such a stable library like libpng I'm not really sure that's a huge boon. Especially since it removes the possibility for compiling for Intel and Apple silicon with the same game.