@acerix I just wanted to check if Clang 3.8 causes issues for Unreal 4.11. I have to role back my version for work.
Search Criteria
Package Details: unreal-engine 5.7.4-1
Package Actions
| Git Clone URL: | https://aur.archlinux.org/unreal-engine.git (read-only, click to copy) |
|---|---|
| Package Base: | unreal-engine |
| Description: | A 3D game engine by Epic Games which can be used non-commercially for free. |
| Upstream URL: | https://www.unrealengine.com/ |
| Keywords: | 3D engine game ue5 Unreal |
| Licenses: | GPL3, custom:UnrealEngine |
| Submitter: | acerix |
| Maintainer: | alexbelm48 |
| Last Packager: | alexbelm48 |
| Votes: | 74 |
| Popularity: | 0.192721 |
| First Submitted: | 2016-05-01 18:37 (UTC) |
| Last Updated: | 2026-03-29 03:16 (UTC) |
Dependencies (31)
- coreutils (coreutils-gitAUR, coreutils-selinuxAUR, uutils-coreutils-gitAUR, uutils-coreutils-git-binAUR)
- dos2unix (dos2unix-gitAUR)
- dotnet-runtime (dotnet-runtime-2.2AUR, dotnet-runtime-3.0AUR, dotnet-runtime-2.1AUR, dotnet-runtime-preview-binAUR, dotnet-runtime-binAUR)
- dotnet-sdk (dotnet-sdk-2.2AUR, dotnet-sdk-2.2-vs2017AUR, dotnet-sdk-3.0AUR, dotnet-sdk-2.1AUR, dotnet-sdk-preview-binAUR, dotnet-sdk-binAUR)
- findutils (findutils-gitAUR, findutils-selinuxAUR)
- lld (llvm-gitAUR)
- openssl (openssl-gitAUR, openssl-staticAUR, openssl-aegisAUR)
- python
- sdl3 (sdl3-noibus-gitAUR, sdl3-gitAUR)
- steam
- vulkan-icd-loader (vulkan-icd-loader-gitAUR)
- xdg-user-dirs
- git (git-gitAUR, git-glAUR, git-wd40AUR) (make)
- glibc (glibc-gitAUR, glibc-eacAUR, glibc-git-native-pgoAUR) (make)
- grep (grep-gitAUR, grep-compatAUR, rg-grepAUR) (make)
- openssh (openssh-gitAUR, openssh-dnatAUR, openssh-gssapiAUR, openssh-hpn-shimAUR, openssh-selinuxAUR) (make)
- rsync (rsync-gitAUR, rsync-reflinkAUR) (make)
- sed (sed-gitAUR, uutils-sedAUR) (make)
- wget (wget-gitAUR) (make)
- clionAUR (optional) – IDE for projects
- Show 11 more dependencies...
Required by (2)
- colosseum
- ue4cli-git (optional)
Sources (7)
Latest Comments
« First ‹ Previous 1 .. 76 77 78 79 80 81 82 83 84 Next › Last »
zerophase commented on 2016-06-16 21:08 (UTC)
acerix commented on 2016-06-09 15:40 (UTC)
@zerophase
As I understand, `make` uses MAKEFLAGS from the environment, so that usage in linux-ck is redundant.
https://www.gnu.org/software/make/manual/html_node/Options_002fRecursion.html
Thanks for the info, I'll add back Source and Intermediate. I also ran into problems after cleaning up the install but didn't have a chance to track down what was missing yet.
If someone wants the engine without that source, I think it would be best to move that to another package name (eg. like in the bitcoin package), but it seems pretty useless without the source, so I'll just include it for now.
zerophase commented on 2016-06-08 19:01 (UTC) (edited on 2016-06-09 06:01 (UTC) by zerophase)
@acerix
On the linuk-ck package the make command is setup like so. "make ${MAKEFLAGS} LOCALVERSION= bzImage modules"
I'm just wondering if without having ${MAKEFLAGS} specified explicitly in the build step, if the MAKEFLAGS setting is applied, or not to make.
Just noticed the current pkgbuild doesn't copy the Source and Intermediate directory over. both are needed if writing C++ is desired. Could you add a bool to the start of the package that flags on adding the entire contents of the Source and Intermediate directories?
acerix commented on 2016-06-08 16:56 (UTC)
@zerophase
I'm not sure if this is what you are asking, but MAKEFLAGS can be specified in /etc/makepkg.conf.
zerophase commented on 2016-06-04 01:39 (UTC)
@acerix
Yeah, I put -j24 in the first time, which makes sense it would fail. (works great for compiling kernels) The next time I built after deleting everything, and redownloading didn't put a -j argument in, and still it failed at the same point. Just had to try compiling again. Wonder if I have an excuse to go up to 64 gigs of ram. I'm saving to disk, and using makepkg directly to build.
Do the MAKEFLAGS get dropped in, even if it isn't specified, in the build step?
acerix commented on 2016-06-03 22:58 (UTC)
@zerophase
Unfortunately, makepkg does not support shallow clone, and Allan says "Won't implement":
https://bugs.archlinux.org/task/34677
However, I think it's a good suggestion seeing how the saving would be about 7 GiB here, and git+ssh seems like the only way to download from a private github repo, so maybe this feature would be considered again for this use case. Another option is to modify makepkg:
https://www.reddit.com/r/archlinux/comments/3nz1r4/question_for_arch_devs_makepkg_and_git_why_not/cvsu79m
Regarding the build, it does support multicore building and I didn't have any issue doing a clean build using -j4. You might be running out of memory trying to build so many things as once; especially since it seems to spawn 4 clang processes for each make process, so that would mean 96 running at once. Let me know what errors you get in the output if it happens again.
zerophase commented on 2016-06-03 05:16 (UTC)
I don't know what the issue is exactly, but the first time I ran makepkg the build failed. The second time I ran the command make fixed whatever went wrong, and installed successfully. It might be that I have MAKEFLAGS set to -j24. I'm guessing the engine isn't configured for multicore compilation, so maybe try -j1 after the make command?
zerophase commented on 2016-06-03 03:03 (UTC)
is there anyway to get makepkg(without editing makepkg itself) to just use a shallow git clone, so we don't have to download the entire Unreal history?
acerix commented on 2016-05-16 15:28 (UTC)
No problem, glad you got it working. It doesn't really make sense for the GUI to disappear for that long, especially when they have loading screens for other stuff. I added a note on this to the Arch wiki.
madsciencecoder commented on 2016-05-15 23:03 (UTC)
Oh wow, it was user error. Clicking yes to recompile the project works, it just runs completely in the background showing no sign of actually doing anything. If you don't open it through a terminal the only way to notice it is to look at the processes with ksysguard/htop/etc. When I first clicked yes I probably rebooted before it could finish and didn't notice it was actually compiling it.
Thanks so much for the help!
Pinned Comments
alexbelm48 commented on 2026-03-28 22:40 (UTC) (edited on 2026-05-16 08:26 (UTC) by alexbelm48)
I currently recommend building
5.6.1over any version of5.7as this branch holds a notoriously broken Vulkan RHI implementation, leading to unexpectedVK_ERROR_DEVICE_LOSTcrashes due to a race condition. Just modifypkgveron 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:
DefaultEngine.ini(either in your project or the editor's installation dir,/opt/unreal-engine/Engine/Config/DefaultEngine.iniby default)ConsoleVariables.inifile (/opt/unreal-engine/Engine/Config/ConsoleVariables.iniby default):alexbelm48 commented on 2026-03-20 16:42 (UTC) (edited on 2026-03-28 23:25 (UTC) by alexbelm48)
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:
You can, of course, replace
kwin_x11with your desktop environment window manager (GNOME ismutterfor example).Neko-san commented on 2022-11-01 02:32 (UTC) (edited on 2023-06-25 01:19 (UTC) by Neko-san)
@juancarlospaco this is easily done on your own system, not in a PKGBUILD, given that building packages runs as root:
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
777permissions. 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).