Add early support for Apple Silicon (M1) build

[GustavoSilvera]

Description

There are several reasons why one might want to build CARLA on the M1 devices, not least of which is the incredible performance they house in a tiny form-factor. Here I present some changes that I needed to build CARLA on my M1 MAX machine.

• Allow >clang-8 building
• Unified Linux and Mac .sh scripts as Unix build scripts
• Add necessary flags to make LibCarla && make launch && make package in x86_64 Apple (Run on rosetta)
• Add necessary flags to make LibCarla && make PythonAPI && make check in arm64 (runs natively)
• Does not change the Linux/Windows build
• Add documentation for Mac build (see Docs/build_mac.md)

Fixes #150 (but specifically for M1 devices)

Where has this been tested?

• Platform(s): MacOS 12.1, Linux (Ubuntu 21.04), Windows 10
• Python version(s): Python3.8 - Anaconda
• Unreal Engine version(s): 4.26-carla (modded by Carla). See this PR

Possible Drawbacks

• Unforeseen challenges with CARLA in multiple architectures
• Additional maintenance with CARLA for MacOS users
• Unable to build PythonAPI in x86_64 mode
• Unable to build PythonAPI with -ljpeg and -ltiff for now
• Need to make LibCarla twice, once in x86 mode and once in arm64 mode

---

This change is 

[update-docs]

Thanks for opening this pull request! The maintainers of this repository would appreciate it if you would update our CHANGELOG.md based on your changes.

[jdrew1]

Hey, I'm building on my 2020 13 inch M1 MacBook Pro on macOS 12.3.1
I started with a fresh re-install of my system, then installed the pre-reqs.
when running brew install --build-from-source mono
I got the following errors:

==> ./configure --prefix=/opt/homebrew/Cellar/mono/6.12.0.122_1 --enable-nls=no
==> make
6 errors generated.
make[5]: *** [libmonoutils_la-mono-context.lo] Error 1
make[5]: *** Waiting for unfinished jobs....
make[4]: *** [all-recursive] Error 1
make[3]: *** [all] Error 2
make[2]: *** [all-recursive] Error 1
make[1]: *** [all-recursive] Error 1
make: *** [all] Error 2

I got around this error by using the auto-installer at https://www.mono-project.com/docs/about-mono/supported-platforms/macos/
(I used the visual studio compatible version if that matters)
[upon further review, the issue stems from wiping my system beforehand: to fix, just make sure rosetta 2 is installed]

---

I was able to build and install the UE4 branch by downgrading from Xcode 13.3 to 13.2.1

---

'make LibCarla' succeeded without issue,
but when I ran 'make PythonAPI' I get the following error:

BuildOSM2ODR.sh: Success!
BuildPythonAPI.sh: Building Python API for Python 3.
Error processing line 1 of /opt/anaconda3/lib/python3.9/site-packages/distutils-precedence.pth:
Traceback (most recent call last):
File "/opt/anaconda3/lib/python3.9/site.py", line 169, in addpackage
exec(line)
File "", line 1, in
ModuleNotFoundError: No module named '_distutils_hack'
Remainder of file ignored

'make check' fails with three copies of the following error

ModuleNotFoundError: No module named 'conda'

---

Any help or advice would be greatly appreciated, thanks! :)

[GustavoSilvera]

Hi, not sure why you are getting this problem with mono, but it seems like you found an alternative. Conda might be giving problems if you are using an x86 version (or building Python for x86), so make sure all the python builds are in arm64 mode. To do this follow the documentation here (at the bottom) where I discuss how to build LibCarla in x86 and arm64 mode.

[jdrew1]

Hey, I tried to install again, starting with another system wipe and os reinstall.

---

I was able to fix the issue when building the PythonAPI, and I'm pretty sure the issue is with the version of setuptools
I found the missing _distutils_hack package at https://github.com/pypa/setuptools/tree/main/_distutils_hack and added it to my python environment

---

I double and triple checked that I built everything in the correct architecture, and that wasn't the problem.

Rather embarrassingly, I missed point 5 under the BUILD CARLA section of the doc. I installed the built module with pip install ./PythonAPI/carla/distcarla-0.9.13-cp38-cp38-macosx_11_0_arm64.whl and then make check returned a success.

I would recommend adding a comment in the docs after the make PythonAPI command, reminding users to actually install the freshly build module, and help avoid future confusion.

Once again, thanks for an amazing patch, your work is greatly appreciated and very helpful :)

[tubzby]

brew install --build-from-source mono failed :

mono-context.c:422:24: error: no member named '__r' in 'struct __darwin_arm_thread_state64'
        memcpy (&mctx->regs, &UCONTEXT_REG_R0 (my_uc), sizeof (host_mgreg_t) * 16);

mono: mono-6.12.0.122
macos: 12.3.1
MacBook pro m1

I post a comment here: mono/mono#10016 (comment)

[DrickCode]

Hi Gustavo,

Ive tried to build with your patches both in Carla and Unreal.
Do you meet the problem of opening UE4editor and it stick on loading in 95%?

I'm running on MacBook Pro x86

[GustavoSilvera]

First off, these patches are specifically for getting carla to build on the m1/m2 devices (Apple silicon) but as long as you followed the directions to build PythonAPI/CarlaUE4 for x86-64 (as if it were running through rosetta) then I guess this works.

Anyways, make sure to check your CPU utilization when the Editor is stuck at 95%, it is normal for on the first build this utilization to be high as UE4 will be compiling shaders and cooking assets prior to opening the scene. So TL;DR: just wait it out, it shouldn't take longer than 30m and its only on the first time you open Carla (building caches)

Another thing you can try to test otherwise is make package which should all be cmd-line based and should output some useful build logs.

[DrickCode]

yes you are right, after finishing my lunch the editor works but is still building
thanks for your great work!

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.