O3DE 4.20 - Development Build - Compilation Guide - Arch Linux

Guide Notes (250517)

This guide is a walkthrough regarding how to compile the Open 3D Engine version 4.20 Development build on Arch Linux from the source available on the Github repository.

This process doesn't come without issues as we will need to make some manual corrections to some source files as the default code doesn't compile without error. This will be further explained below in this guide as required.

Build Requirements

This build process will be completely on the terminal. Whatever terminal application you use is completely up to you but I will assume at this point that you have all the required tools and libraries installed to start the O3DE build process; such as cmake, git lfs etc.

Some of the build configuration such as directory locations are based on how I choose to do it. Feel free to adapt these to your needs/preferences as required.

Compilation Instructions

Pre-Build

A compatible version of Python will be installed into the local copy of the repo and configured for the O3DE build. This is required as the version of Python that may be pre-installed and available at the system level may not be compatible with the O3DE build process so O3DE provides its own.

Cmake

As I prefer to develop O3DE Projects with the potential to make deep changes to the O3DE source itself, I like to build the CMake files for the Debug build. You can alternatively use the Profile or Release build as preferred if debug symbols etc are not a requirement for your needs.

• I will be generating build files for Ninja but you can alternatively generate for alternative types such as for Unix Makefiles if that is preferred.
• I will also be using ccache to speed up re-compilations as required but that can be optionally removed if you don't require it.

$ cmake -B build/linux -S . -G "Ninja" \
> -DCMAKE_BUILD_TYPE=Debug \
> -DCMAKE_C_COMPILER_LAUNCHER=ccache \
> -DCMAKE_CXX_COMPILER_LAUNCHER=ccache \
> -DLY_3RDPARTY_PATH=3rdParty

First Build Error

CMake Error at build/linux/_deps/recastnavigation-src/CMakeLists.txt:1 (cmake_minimum_required):
  Compatibility with CMake < 3.5 has been removed from CMake.

  Update the VERSION argument <min> value.  Or, use the <min>...<max> syntax
  to tell CMake that the project requires at least <min> but has been updated
  to work with policies introduced by <max> or earlier.

  Or, add -DCMAKE_POLICY_VERSION_MINIMUM=3.5 to try configuring anyway.

At this point, during the generation process of these build files the first potential CMake error occurs regarding an incompatible version within the recastnavigation dependancies CMakeLists.txt file.

This occurs for me because I use CMake version 4. For compatibility reasons CMake 4 isn't compatible with any CMakeList.txt files that are versioned before 3.5. In this case recastnavigation is versioned at 3.0.

This is an easy fix. We can just modify this CMakeLists.txt file and change its version from 3.0 to 3.5 to allow the build process to continue.

At this point it is required to restart the build process by running the previous CMake command again. Don't worry, it wont be a complete restart. It will skip past everything that it has already done and continue from where it left off (at recastnavigation) where the error previously occured.

Once that has completed we can then Compile O3DE.

$ cmake --build build/linux --target Editor

This will take a while, and unfortunately another CMake error will occur. We will deal with that when it happens.

Second Build Error

This error will include ...

In file included from .../o3de/Gems/Atom/RPI/Code/External/MaskedOcclusionCulling/MaskedOcclusionCullingAVX512.cpp:20:
.../o3de/Gems/Atom/RPI/Code/External/MaskedOcclusionCulling/CompilerSpecific.inl:79:20: error: redefinition of '__cpuidex'
   79 |         FORCE_INLINE void __cpuidex(int* cpuinfo, int function, int subfunction)
      |                           ^
/usr/lib/clang/19/include/cpuid.h:345:22: note: previous definition is here
  345 | static __inline void __cpuidex(int __cpu_info[4], int __leaf, int __subleaf) {
      |                      ^
1 error generated.

I'll admit I had trouble finding any information online regarding this error. I searched Google and even searched through the O3DE Github issue listing and forums but couldn't find anything specific to this error. I am not sure if my google skills were failing hard that day or no one else was coming across this problem or it was just somehow related to my setup.

I did end up consulting ChatGPT regarding this error and as far as I know it gave a very good explanation of the problem, what was causing it, along with how to resolve it.

Apparently, its a conflict between a hand-written function in a O3DE Gem and a built-in compiler instrinsic in Clang, in regards to a redifinition of __cpuindex which is a low-level CPU instruction wrapper. And is a known compatibility issue with Clang when building O3DE, especially in regards to the MaskedOcclusionCulling library.

This also explained why I didn't get this compilation error with Windows when compiling within Visual Studio with MSVC.

The fix is simple as wrapping the __cpuidex function inside CompilerSpecific.inl within a _MSC_VER preprocessor definition block. This will cause this function to not be compiled if the compiler is not MSVC as in this case Clang already provides built-in equivalents and is not required for a Linux build.

$ nano Gems/Atom/RPI/Code/External/MaskedOcclusionCulling/CompilerSpecific.inl

#if defined(_MSC_VER)
FORCE_INLINE void __cpuidex(int* cpuinfo, int function, int subfunction)
{
        __cpuid_count(function, subfunction, cpuinfo[0], cpuinfo[1], cpuinfo[2], cpuinfo[3]);
}
#endif

At this point it is required to restart the build process again by running the previous CMake command. As previously, it will resume from where it left off which in this case is fortunate as this part of the build process is the most time consuming and depending on the performance of your computer it can take quite a long time.

You should be good from this point forward, just let the compilation process continue until the end at which point you will have a fully compiled and ready to use build of O3DE.

Other Considerations

It should be noted that the first build error regarding the CMakeLists.txt file within recastnavigation will also occur independently within your O3DE project files. As these compile they will have this same build error and will require the same resolution to fix.

This is unfortunate. I guess the dependencies for Project code generation is independently pulled so don't automatically include the corrections we already made to the O3DE source files.