Change:
<del> #!/bin/sh go() { file="$1" IFS=$'n' for pack in $(perl -n -e '/(<Pack .*/>)/ && print "$1n"' $file); do remotepath=$(echo "$pack" | perl -n -e '/RemotePath="([^"]*)"/ && print $1') hash=$(echo "$pack" | perl -n -e '/Hash="([^"]*)"/ && print $1') url="http://cdn.unrealengine.com/dependencies/$remotepath/$hash" until sha256=$(nix-prefetch-url $url --type sha256); do true done cat <<EOF "$hash" = fetchurl { url = $url; sha256 = "$sha256"; }; EOF done } cat <<EOF { fetchurl }: { EOF go Engine/Build/Commit.gitdeps.xml go Engine/Build/Promoted.gitdeps.xml cat <<EOF } EOF </del>

Discussion:
I'm trying to fix the Unreal Engine 4 package on the latest nixpkgs master (commit ). It looks like it was using a deprecated version of clang. I changed clang to 3.6 (recommended for the latest ue4 release), changed the ue4 release version to 4.12.5, and updated the pkgs/games/ue4/cdn- file with the shell script included with the derivation. The UE4Editor binary compiles, but it wants to link with , but cannot do so properly (I assume because clang does not use libstdc++) and refuses to run. I tried linking with libstdc++ manually but I quickly run into malloc/free errors, which leads me to believe this conflicts with whatever C library clang is using. There are a number of pre-compiled third party binaries that come with ue4 that link with libstdc++, so I don't know if linking with libstdc++ can be avoided. Does anyone think they can fix this package? I would appreciate it.
Just a quick update: I have this working. A pull request is forthcoming. I'm just trying to figure out how to get UE4Editor to find a C++ toolchain. Whether or not I figure that out, I'll submit a pull request in a few days.
Usually this is done by using :
did you ever finish this?
can you maybe share your work so others can finish it?
After spending some time trying to fix it myself I think the best approach is to use nix-shell rather than doing proper packaging. The furthest I got is the following On my laptop I can build the engine in that shell, it displays loading screen, and then exits with a message that it can't initialize opengl 4 window. It could be that it's purely because my laptop's intel gpu is not good enough for UE4. didn't solve the problem as it were trying to initialize opengl 3.3 or something, and max supported version for my gpu was 3.2 if I figured it out correctly.
Thank you for your contributions. This has been automatically marked as stale because it has had no activity for 180 days. If this is still important to you, we ask that you leave a comment below. Your comment can be as simple as "still important to me".

This lets people see that at least one person still cares about this. Someone will have to do this at most twice a year if there is no other activity. Here are suggestions that might help resolve this more quickly: for maintainers and people that previously touched the related code and @ mention them in a comment. on the . on the on .
This is very important to me; no idea if I have the time or skill to make it work; but it should be important to us all. Nix and UE4 are the perfect match; both in workflow, and development. Having UE4 and it's editor running reliably under Nix(OS) will allow for the perfect one click deployable dev-workstation.
Unreal Engine build how-to states clang 3.5-3.9 is required. But only clang = 5 is available starting from nixos-20.03. The same thing for mono, version 3 is required, version = 4 is available. Either UE build instructions are outdated, either it's hardly build-able on recent distros. By the way, wiki suggests to use ubuntu-16.04 :(
Looks like most build instructions are outdated, while the engine itself is ok. I was able to build ue-4.26 in ubuntu18.04 docker container with mounted ut4 source directory. After some binary patching (for LD INTERP) and adding some libraries (udev and vulkan) to expression posted above by ue4editor now happily works in a nix-shell environment in my nixos. Building it in nixos is another story, though. The beast seem to be almost fully self-contained, It use nothing from host system apart from libudev, It downloads all the dependencies using some .NET binary then you run . One of dependencies is being clang, and of course it requires patchelfing too :)
I'm working on this and would appreciate any help: Here is my latest so far:
to save a hour of waiting, here're the compile logs for patch by from the post above.
I see there're basically two problems now: several instances of this: I guess, it should be easy to fix, e.g.

we just just need to suppress the effect of somehow a bunch of errors related to duplicate std c++ library symbols during linking, like following: Here we see symbols from system clashing with ones from . I wonder why they supply their-own version, given it's a pretty standard stuff.
I've managed to launch after tinkering with work for a few days. I still see some errors related to the absence of . I used to resolve the problem related to . Though I think suppressing is a better solution.UE4's build tool actually passes to the compiler. However, some third-party library modules, in particular , are built against (see ) and as such declare as their system library dependency. links to such modules and consequently inherits their system library dependencies (this isn't really necessary for s, I think?), which leads to the "duplicate symbols" error. I've filtered out such dependencies by the following patch, which might not be the best approach:(Another option would be to use the system-default by passing . This requires compiling third-party libraries by ourselves (the provided binaries are built against ), which turned out to be harder than I thought.)Since is linked against , it needs to be brought into .needs to be -ed in .
Thank you and I also disabled hardening at some point but didn't figure out a way to get rid of duplicate symbol errors. I think we need to either use libc++ or libstdc++ but not both. I've played around with but it didn't seem to help. I've also tried just patchelfing the entire Linux toolchain from UE's downloaded platform and not doing anything else to patch the codebase, but that led to a different set of errors that seemed harder to solve.
Do you have a branch somewhere I can use to build a working UE4Editor?? That's really fantastic progress.
I just started updating the Nix code to reflect my local changes: are some things left to do: and need to be to . The executable has weird rpaths for some reason and can't find the bundled shared libraries. The editor seems to be operational but, as the above things are missing, still needs additional paths to be manually given. ( is needed to prefer GPU over software rendering, but this could be only specific to my machine.)

To launch the editor:
great work, By the way, UE-4.26.2 was released a week ago or so. AFAIK It contains some nice bug fixes, like properly working custom rendering passes. Maybe we should target updated version?
Updated to 4.26.2: The splash screen is not appearing any more.
I was under impression, you also have to regenerate dependencies with . Or maybe 4.26.2 is a bugfix version and dependencies stay fixed?
Fixed the splash screen: (Help still wanted for the rpaths of .) Yes, I have updated by running . It seems to change a lot between releases.
Awesome! Regard the rpath: Have you tried ing to change just the RPATH? I think you can essentially set LDLIBRARYPATH permanently that way.
I see now that it's referring to things in the source directory. Perhaps you can just copy those to and then specify the RPATH to there since that will be a full nix path.
It actually copies literally everything from the build directory: I could just do manually but I'd rather prefer something automatic so that the future maintainers won't have to readjust the paths on every UE4 upgrade. I have noticed that it hasn't yet enabled , which I think might be able to sort out the rpath problem.
patchelf crashes during :
I tried building by manually launching phases inside Got a bunch of link errors: You certainly don't have these issues, do you? Looks like some nondeterminism is involved.
Strangely, after rerunning I got compiled in just five additional minutes. Unfortunately, it fails on SDL initialization, but I guess its a separate issue. I remember getting similar error when I was experimenting with running on Nixos UE4 built in ubuntu docker. Unfortunately, forgot how to tackle it.
I saw the same error when the X11 libraries were missing. The shell script is responsible for setting to ensure such runtime dependencies can be found. (There are also runtime dependencies on libGL and libvulkan, required by the splash screen and the engine renderer, respectively.)
actually didn't have weird rpaths, but 40 other shared libraries did. s in those shared libraries were prefixed by backslashes for some reason. This was addressed by seems to be specific to systems with no discrete GPUs and llvmpipe listed as GPU0.

Reported as Case #
Got a bunch of link errors during building with nixpkgs: Surprisingly, manual build with nix-shell finishes without any errors. UPDATE. Actually, buildPhase fails on the first run but happily continues, if I repeat the command. If I after that I fix environment variable (to set it to a user-writable place) and run install phase, resulting bash wrapper works and UE4Editor is launched successfully.
It built first time for me, although the Editor crashes on trying to create a C++ project with: Creating a Blueprint project does work, but gives the same error on trying to create a C++ class:
Looks like we need to tell UE where to create intermediate build files. It's trying to use its /nix/store path.
With UE-5 early access out, how much of the existing work is portable? I've not even dared look at it's build system yet, in hopes it's the same.
I marked this as stale due to inactivity. &rarr;
Hey y'all, I'm planning to drop the ue4 package since it's been broken for so long: Is anyone still planning to revive it? I think it makes sense to drop it anyway for now and reinit it if anyone ever gets around to fixing it.
We'll never be able to actually include it since it's not open source. Better to move it to a separate repo where it can be worked on. The amount of work already put into this is enormous and I'd hate to lose that discoverability.
Sorry, what do you mean with discoverability? Keeping this issue open? I'm fine with that, I just think that keeping the build recipe that's broken isn't useful.
It's useful so that people who want UE in Nix can find it easily here and have some hope of getting it working since so much work has already been done.
Please do update the derivation with everything you've found already, that also helps future people looking at it realize that there's still someone working on it. I'll happily merge improvements (even if it doesn't fully work yet) to the derivation if you ping me. If there's still no work done on the derivation, it doesn't make sense to me to keep it, you can maybe link to it (latest commit where it's still available in nixpkgs) here then and we'll drop it.

I a link to this issue above the broken = true line for now for more visibility.
Actually looks like the most up-to-date work is already in various forks linked in this thread. Feel free to drop it.
I think it's time to remove it. No need for the large CDN dependencies file to exist in everyone's download of nixpkgs when it can't even be used.
Yes, I recently built the entire release packageset, and accounts for more than half of the failed jobs. I don't know why isn't failing these jobs too. It must have a private cache for these FODOs that isn't exposed via .