Arch Linux User Repository

@juancarlospaco this is easily done on your own system, not in a PKGBUILD, given that building packages runs as root:

sudo groupadd unrealengine-users
sudo usermod -aG unrealengine-users (your-username)
sudo chown -R root:unrealengine-users /opt/unreal-engine
sudo chmod -R 775 /opt/unreal-engine

Permission issues like this are already mentioned on the UE Arch wiki page: https://wiki.archlinux.org/title/Unreal_Engine_4#Installing_from_the_AUR

This is a user system problem; I already did what I could without needing users to do the above by giving the 777 permissions. If it still gives you trouble, you'll have to use the example to solve it or change the install location to somewhere you have user permissions by default (as I cannot do this for you).

Will update to 5.0 when it is released.

@Shatur Well, I guess I'll have to create a clone of this repo and provide my own patches, then. Perhaps you can put your own build-customization into another pkg. Let the users decide to customize inste...

What build customization do you meant? All of them are disabled by default. Except the fix for GenerateClangDatabase.

UE can be mostly compiled with -j# but some things cannot be built on first run that way and need -j1. I usually run a -j# then again until they succeed.

I just successfully built it on 24 cores without any issue.

Not sure where there is some 30-thread limitation... I also don't see any CPU-specific stuff, considering Intel and AMD builds will run on one another fine. >_>

It was there. I removed this stuff.

Nice work on fixing GenerateClangDatabase and the mono+ccache work. Appreciate the true/false values too. ;)

The mono and ccache patches were already here, I just disabled it by default.

@Shatur, Well, I guess I'll have to create a clone of this repo and provide my own patches, then. Perhaps you can put your own build-customization into another pkg. Let the users decide to customize instead... AUR would benefit from review methods. :)

UE can be mostly compiled with -j# but some things cannot be built on first run that way and need -j1. I usually run a -j# then again until they succeed. Not sure where there is some 30-thread limitation... I also don't see any CPU-specific stuff, especially considering Intel and AMD builds will run on one another fine because they both comply with x86 architecture. Even if vendor-specific flags are used, compilers generate non-vendor-specific in almost all cases. We'd be back in the sc3n3 days to expect otherwise. >_> It looks like you were looking at the default configuration of UE for thread/core utilization during runtime compilation, which should be undone. I'm firmly against commit 0017ada0056f, it has nothing to do with being Intel/AMD-specific or anything, just about how many threads/cores are used to compile when compiling shaders during IDE runtime, etc. This is something that belongs in user-builds, not a pkg.

Nice work on fixing GenerateClangDatabase and the mono+ccache work. Appreciate the true/false values too. ;)

I updated the PKGBUILD. Here is what I did:

1. Switched to "Installed build" generation (https://docs.unrealengine.com/4.26/en-US/ProductionPipelines/DeployingTheEngine/UsinganInstalledBuild/). This is a preferred method of distributing the engine binaries. It takes much less space on disk (because it packages only required stuff) and this is how it packaged for Windows by Epics. The previous build method is mainly used for engine development. It also saves compilation time since UBT no longer checks for the engine code changes.
2. I removed the patch for system compiler support because it causes issues with current clang (12). Also I'm not sure if it possible to apply it to the "Installed build". But the patches in Git history and it can be reintorduced later.
3. I removed the patch that multiplies number of threads for UBT. This is unnecessary because it can be controlled by the MAKEFLAGS=-j<threads_count> environment variable. It also removes hardcoded maximum number of threads (30) and removes project buiding with native CPU instructions. It's not a good idead to build project that bound to the specific CPU by default (for example, if it was compiled on Intel, it will not work on AMD). Let's let users decide, they can easily specify all this stuff locally.
4. Applied a patch that fixes GenerateClangDatabase for Linux. The search mechanism was Windows-specific.
5. I have disabled the mono and ccache patches by default, because it will require user intervention, who cannot read the PKGBUILD carefully. Also, the dependencies for these patches are now dynamically added.
6. I changed patches switches to true / false to make it more obvious for users.
7. Installation path now also an option.
8. Minor PKGBUILD refactoring.

@zerophase, unfortunately, AUR do not have a rereview mechanism, so I did not have the opportunity to discuss the changes with you first :(

So feel free to disagree with any change and undo / remove / rework any commit that I did.

BTW, anyone that want to use UE5 now can simply change the used branch in line 52 to 5.0.0-early-access-2.

@Shatur, Thank you for pointing that out doc out, I'm most definitely interested in it. I wasn't entirely aware of non-Epic means of redistribution of binaries aside from copy-paste. :)

@zerophase, I have some suggestions:

1. Engine/Source/Programs/UnrealBuildTool/Modes/GenerateClangDatabase.cs currently have a hardcoded path to clang for Windows. How about patch it to fix database generation on Linux? Here is the changes: https://pastebin.com/mQYftFnA
2. We could use "Installed build" way to create a package. It will take much less space (~31GB unpacked). Should be done via automation tool, take a look: https://docs.unrealengine.com/4.26/en-US/ProductionPipelines/DeployingTheEngine/UsinganInstalledBuild/ (e.g. just run UnrealEngine/Engine/Build/BatchFiles/RunUAT.sh BuildGraph -target="Make Installed Build Linux" -script=Engine/Build/InstalledEngineBuild.xml -clean -set:WithDDC=false -set:HostPlatformOnly=true after Setup.sh instead of executing build manually)
3. Disable using system compiler to avoid hardcoding clang version in PKGBUILD.

@mihirlad55 the best solution for now is downgrading to clang 11.1. I'm not on Twitter, but try tweeting at Tim Sweeney about this. I think he wrote the initial code. He might be able to fix it really quick.

Ну что, будет обновление до 4.26.2-6? У меня ошибка компиляции текущей версии. То обновления часто, то сейчас блин когда проблемы никто не решает!

@zerophase @zepvalue

I am also segfaulting on startup

Application version 4.26.2.0
 ... built from changelist 0

OS version Linux 5.12.4-arch1-2 (network name: iphone)
Running 4 x86_64 processors (8 logical cores)
Exception was "SIGSEGV: invalid attempt to read memory at address 0x0000000000000038"

libUE4Editor-CoreUObject.so!UStruct::IsChildOf(UStruct const*) const [/home/mihirlad55/.cache/yay/unreal-engine/src/unrealengine/Engine/Source/Runtime/CoreUObject/Private/UObject/Class.cpp:2204]
libUE4Editor-AudioSynesthesiaEditor.so!void FAudioSynesthesiaEditorModule::RegisterAudioSynesthesiaAssetActions<UAudioSynesthesiaNRT, FAssetTypeActions_AudioSynesthesiaNRT>() [/home/mihirlad55/.cache/yay/unreal-engine/src/unreal-engine/Engine/Plugins/Runtime/AudioSynesthesia/Source/AudioSynesthesiaEditor/Private/AudioSynesthesiaEditorModule.cpp:57]
libUE4Editor-AudioSynesthesiaEditor.so!FAudioSynesthesiaEditorModule::RegisterAssetActions() [/home/mihirlad55/.cache/yay/unreal-engine/src/unreal-engine/Engine/Plugins/Runtime/AudioSynesthesia/Source/AudioSynesthesiaEditor/Private/AudioSynesthesiaEditorModule.cpp:31]
libUE4Editor-Core.so!FModuleManager::LoadModuleWithFailureReason(FName, EModuleLoadResult&) [/home/mihirlad55/.cache/yay/unreal-engine/src/unreal- engine/Engine/Source/Runtime/Core/Private/Modules/ModuleManager.cpp:536]
libUE4Editor-Projects.so!FModuleDescriptor::LoadModulesForPhase(ELoadingPhase::Type, TArray<FModuleDescriptor, TSizedDefaultAllocator<32> > const&, TMap<FName, EModuleLoadResult, FDefaultSetAllocator, TDefaultMapHashableKeyFuncs<FName, EModuleLoadResult, false> >&) [/home/mihirlad55/.cache/yay/unreal-engine/src/unreal-engine/Engine/Source/Runtime/Projects/Private/ModuleDescriptor.cpp:560]
libUE4Editor-Projects.so!FPluginManager::TryLoadModulesForPlugin(FPlugin const&, ELoadingPhase::Type) const [/home/mihirlad55/.cache/yay/unreal-engine/src/unreal-engine/Engine/Source/Runtime/Projects/Private/PluginManager.cpp:1293]
libUE4Editor-Projects.so!FPluginManager::LoadModulesForEnabledPlugins(ELoadingPhase::Type) [/home/mihirlad55/.cache/yay/unreal-engine/src/unreal-engine/Engine/Source/Runtime/Projects/Private/PluginManager.cpp:1369]
UE4Editor!FEngineLoop::LoadStartupModules() [/home/mihirlad55/.cache/yay/unreal-engine/src/unreal-engine/Engine/Source/Runtime/Launch/Private/LaunchEngineLoop.cpp:3822]
UE4Editor!FEngineLoop::PreInitPostStartupScreen(char16_t const*) [/home/mihirlad55/.cache/yay/unreal-engine/src/unreal-engine/Engine/Source/Runtime/Launch/Private/LaunchEngineLoop.cpp:3198]
UE4Editor!GuardedMain(char16_t const*) [/home/mihirlad55/.cache/yay/unreal-engine/src/unreal-engine/Engine/Source/Runtime/Launch/Private/Launch.cpp:127]
libUE4Editor-UnixCommonStartup.so!CommonUnixMain(int, char**, int (*)(char16_t const*), void (*)()) [/home/mihirlad55/.cache/yay/unreal-engine/src/unreal-engine/Engine/Source/Runtime/Unix/UnixCommonStartup/Private/UnixCommonStartup.cpp:264]
libc.so.6!__libc_start_main(+0xd4)

@zepvalue. Seems to be an issue with Clang 12. It's a run time bug.

@zerophase It happened before anything was built.

Apparently there was no directory /etc/mono/registry/LocalMachine. Got around it by manually creating it.