if i am added only one x86_64 then getting these errors…
1 Like
i did following changes. can’t able to run in simulator… i am sharing ss for ref.
@R101 i am sharing all my ss…
please help me.
@AGamer I am not sure whether M1 is supported or not.
But for your error I think you need to exclude arm64 for iOS simulator.
This is how we handle for xcode 12.4 and its working for us.
Edit:
May be you need to delete VALID_ARCHS whole entry as well.
If you search in build_settings then you should not see anything.
After this only it worked for me.
Not sure for M1 machines though.
I’ve seen that error before, but I can’t quite remember why it happens. Did you clear you build folder, or at least delete [build folder]/CMakeCache.txt, after changing the settings in your CMakeLists.txt?
It could be a problem with the cocos2d/cmake/ios.toolchain.cmake file, in terms of what settings it has. Open it up and see if there’s anything obvious in there, and compare it to a working version.
@smitpatel88 thank you for your kind response & support. i already did all these steps… but not working in m1 may be…but i am trying to resolve this…
@R101 please can you put a full video for all these changes? because i did some change but honestly i did not understand what more change i have to do in CMakeLists.txt. so please can you put small video link it’s really needful to all who are using m1… thanks again @smitpatel88 @R101
@smitpatel88 @slackmoehrle @bilalmirza @Algoritmiik @vkreal2 @R101 thank you all for your response… finally i can run my cocos2dx project on xcode 13 in mac m1 with big sur…
i am attaching all screenshot how i can run you can refer it also if you have any query please let me know
1 Like
@vkreal2 yes… definitely, follow all beloved steps.
- force quite xcode right click it and tick-mark “open using rosetta” se above screenshot.
- change excluded architectures and valid architectures as per the screenshot in build setting in xcode.
- put version code(number) whatever you want as mentioned in screenshot.
- in (search in xcode) btvector3.h replace line
“#define BT_SHUFFLE(x,y,z,w) ((w)<<6 | (z)<<4 | (y)<<2 | (x))” with following line
“#define BT_SHUFFLE(x, y, z, w) (((w) << 6 | (z) << 4 | (y) << 2 | (x)) & 0xff)”
those all are valid steps you can execute for m1…and it’a absolutely running perfect…
thanks.
1 Like
I have asked our engineering team how we could go about testing this. I don’t know what their process will be.
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.
4 Likes
Indeed. For M1 there is by the way no need to build for simulator. The M1 can just natively run the iOS builds.
1 Like
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.
1 Like
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.