The solution presented by @AGamer is a work-around, and should only be considered to be a temporary measure. The files are being compiled as the x86_64 architecture, and use Rosetta to work on hardware with ARM instruction-set processors.
The actual solution should be to build native libraries for ARM, as @pinky2012 mentioned earlier up in this thread.
In terms of iOS simulator support, x86_64 is the way to go, since providing ARM-specific simulator libraries is more effort than it’s worth, and the x86_64 version of the simulators work perfectly on the M1 chip.
Indeed. For M1 there is by the way no need to build for simulator. The M1 can just natively run the iOS builds.
hello everyone… right may be it’s temporary… but i perfectly run my 4 games via this… i did not faced any issues… so let me know if anyone can find permanent solution… thank you.
Well, i actually already gave you the permanent solution. There is nothing more to do than add the arm libraries to your project and link against them when building for apple silicon. That’s it.
Most difficult part would be finding the arm libraries for all dependencies but as I wrote earlier most of them would be available in Cocos Builder. Just copy them from there and find prebuilt libs via Google for the rest of them (or alternatively build them yourself, what I for example did for the Nakama library my app uses). This is btw also a good moment to see if you need some of the dependencies at all (i removed several of them because my app does not use the specific libs at all).
Well it’s not simple really. The deps are maintained by the Cocos2d-x team so why haven’t they been updated yet? The M1 has been out for nearly a year now.
Actually it is simple. I did it in 2 hours and I am by no means an expert. The dependencies are most all third party libraries that have long been compiled for M1 as well. Perhaps not by the Cocos team, but why wait for them. As said you can find these libraries as part of CocosCreator of just by using Google. Homebrew is also a good place to find most of the dependencies. Most of them are opensource so you could just download and compile yourself as well (as most of these have been readied for M1 as well).
You would want to find (or create with lipo) universal libraries containing both X64 and Apple Silicon (arm64) versions and just replace the current Mac ones with the new “fat” ones.
So the steps I followed:
1- Find Universal versions of all dependencies for Mac (start with the ones in Cocos Creator as these are already universal). (i.e. libpng.a, lipjpeg.a. etc.)
Start your quest here => engine-native-external/mac/libs at v3.4.0 · cocos-creator/engine-native-external · GitHub
2- Replace the original libs and headers for Mac with these new ones (in cocos2d/external folder)
3- Change the project to build for Intel & Apple Silicon
4- Build and be amazed when it just works
Before I started I first cleaned up my dependencies (for example, I don’t use tiff files, so I did not bother to find universal libraries for that… just removed it from the project).
No, no. Simple is:
% cd cocos2d-x
% python download-deps.py
That’s the way it was designed to work and it hasn’t been updated in a long time. Are there 64-bit versions of the Windows libraries yet?
When the source tree isn’t maintained then users walk away and the framework dies. This has been happening for a while with Cocos2d-x.
That’s true. But complaining won’t get you nowhere. Solving problems yourself does.
We are focusing on the underlying engine and at some point these changes may be reflected in cocos2d-x.
If I had an M1 I would help fix these issues.
You don’t need an M1 Mac to fix the issue. What is needed is to update the cocos2d-x-3rd-party-libs-src repo so it builds x86_64 and arm64 fat binaries for the Mac deps. This can be done on an Intel Mac.
If you look at the forks network in GitHub you can see some users have attempted this, however when I cloned one of those repos, to try and build the deps, it failed, so the work is not complete.
Once that repo is updated you can rebuild the zip file that users will download into their copy of Cocos2d-x.
This is how you solve the issue for all users in a managed, reproducible way rather than scavenging binaries from here and there.
I am aware that X86_64 should work but I don’t know if it’s full proof at this point. @R101 what do you think?
The x86_64 runs fine on the M1 Mac via Rosetta, and my main concern was regarding enabling Rosetta; I don’t know if it can be enabled automatically on installation, or the end-user needs to turn it on manually for the specific binary (I don’t think it can be enabled system-wide, but I could be wrong).
In terms of performance, running x86_64 on the ARM hardware seems to be equivalent to running on the native x86_64 hardware, but I can’t give you specific numbers.
Ideally there should be arm64 native binaries though……to avoid Rosetta entirely.
@pinky2012 Hi! i was working on this issue today (m1 build) compiling the libraries but i cant seem to find glsl_optimizer anywhere, any ideas?
Sorry, can’t help you there. My project does not use that library ( I guess you are at Cocos 4.0?). Seems the sources are available though, so you could try to compile it for ARM yourself.
Hi all, I got in the same issues when trying to build cocos for Mac. I compiled most dependencies for M1. I can build cocos2dx with or without Lua using directly cmake, and it is available on my GitHub.
Just to be sure, for iOS, this arm64 libs I did build for Mac are not compatible and I need to rebuild a new set of libs for iOS even when Mac and iOS are both arm64. is that correct?
@papalma your repo can run cocos native Apple M1 without Rosetta right?