Arch Linux User Repository

I currently recommend building 5.6.1 over any version of 5.7 as this branch holds a notoriously broken Vulkan RHI implementation, leading to unexpected VK_ERROR_DEVICE_LOST crashes due to a race condition. Just modify pkgver on your end with the aformentioned version and you should be good to go.

A discussion here goes into detail about the issue, but no proper fix is currently planned by Epic.

A merge request has also been proposed here, but the fix itself was in the end apparently not very effective.

The Vulkan crashes were recently fixed in 5.8, check here.

You can still try on your own if you still insist on using 5.7.x, especially if you're motivated to fix this issue on your side. If so, don't hesitate to send a comment with your patch, I could add you as a contributor to this package if you are interested.

Reducing crashes can be done by doing the following two steps:

• Add these lines in DefaultEngine.ini (either in your project or the editor's installation dir, /opt/unreal-engine/Engine/Config/DefaultEngine.ini by default)

[/Script/Engine.RendererSettings]
r.Vulkan.WaitForIdleOnSubmit=1
r.Vulkan.EnablePipelineLRUCache=1

• Add these two lines as well in the editor's ConsoleVariables.ini file (/opt/unreal-engine/Engine/Config/ConsoleVariables.ini by default):

Slate.EnableToolTips=0
Slate.bAllowNotifications=0

Do note that using Wayland for Unreal Engine is currently not recommended as half of the UI interactions are broken. This is due to a recent upgrade to SDL3 which defaults the use of Wayland protocols over X11 when launching on a Wayland-based session.

You can work around this (or at least improve your experience) while still being on Wayland by opening a separate Xorg windowed server:

export DISPLAY=:1

Xwayland ${DISPLAY} -decorate -geometry 1920x1080 &
kwin_x11 &
unreal-engine 

You can, of course, replace kwin_x11 with your desktop environment window manager (GNOME is mutter for example).

@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).

@zerophase, as you wish. As I said before - feel free to revert any my commit. Each commit contains a standalone change, it should be easy. It's weird that the compilation doesn't work in temp folder for you. I used bundled mono that downloaded by default by UE.

@shatur There's probably a work around for this. I'll have to look into how Unreal Engine 5 compiles everything. Think I should be able to use the system mono to address the permission issues.

I would recommend reverting the automation tool till it supports the system mono too. I'm pretty sure this is an issue with the mono used.

@zerophase, got it, I used another directory on my drive because I simply do not have enough space in temp.

It's a permission issue from building in temp. Automation tool causes the issue as well. We should try to avoid saving files to home while building.

@zerophase, I compiled developer preview 2 successfully, just changed the branch name in the current latest PKGBUILD.

Trying to compile Unreal 5. I keep getting this error. Does anyone know how to fix?

https://pastebin.com/YKPM3gFT

Does UAT fully support C++ projects? That's all I really worry about.

Sure! Projects compilation is also noticeably faster.

We should be using BuildConfiguration.xml, as UBT does not necessarily respect MAKEFLAGS. Their build system definitely manually changes some of those values, like passing make more jobs I'd love to have it setup to support large core count cpus, as I use them personally. I just don't think the average user has 24+ cores.

Sorry, maybe I didn't get it something... MAKEFLAGS work both when building the engine and when compiling C++ projects. I tested it myself. Why hardcode the number of cores?

Users that want custom build configurations can just modify the file before compiling with makepkg, and use something like Paru to make their changes permanent for updates.

I only turn features on by default if they're accepted upstream.

Of course! But I disabled the system mono patch by default because this requires user intervention after. But feel free to enable it if you think otherwise. Has the ccache_executor.patch patch been accepted in 5.0 / 4.27? I missed it.

@shatur Does UAT fully support C++ projects? That's all I really worry about. It might complicate any modifications on our part to better support Arch Linux.

I just put a thread limit in there as I didn't know how all cpus scale with that multiplier.

We should be using BuildConfiguration.xml, as UBT does not necessarily respect MAKEFLAGS. Their build system definitely manually changes some of those values, like passing make more jobs. Sticking to how UBT works should make maintence easier.

Users that want custom build configurations can just modify the file before compiling with makepkg, and use something like Paru to make their changes permanent for updates.

I'd love to have it setup to support large core count cpus, as I use them personally. I just don't think the average user has 24+ cores.

I only turn features on by default if they're accepted upstream.

@zerophase, I don't think this is a good idea. UAT is the preferred way for binary deployment. It also doesn't require any additional dependencies. According to my observations, it not only builds the project and removes all unnecessary junk, it also creates a special file that forces UBT not to check the changes in the engine. It just my observation, maybe it does something else! Doing all this stuff manually simply not worth it. And it will be hard to maintain.

Also I do not think that hardcoding the number of threads by default is a good idea :) You can simply use MAKEFLAGS as I do. I bet the users want to have an unmodified version of the engine. Check out our conversation @OdinVex.

--march=native is good for building the engine itself, but building projects using this flag is bad because they will be tied to the CPU it was built on.

I would go back to using make for building, and just run all of the UAT stuff manually. All you're doing is abstracting package maintenance into the automation system, which requires dependencies to use. I guess just diff the directory differences, and just remove the unneeded files during the package step.

There's a 30 thread limit put in to cap how high the multiplier scales for systems with less cores, while maintaining responsiveness. If you need more than thirty cores, build manually with makepkg, or let paru manage your local PKGBUILD with git. That multiplier is there to speed up compilation, as much as possible, without negatively impacting the responsiveness of said system. It's not our responsibility to maintain the PKGBUILD for your specific system.

-march=native is fine for compiling for most newer cpus, and should only be turned on if you're willing to test it. Works perfectly fine for Haswell and Broadwell cpus. Plus you need to pass a command line argument to enable it. I turned on looking for bugs with other cpus, as it got accepted upstream. Maintaining and patching the Unreal Build System is the solution, not MAKEFLAGS. UBT manages each subproject, and won't necessarily play nice with variables from outside.