I just got this link last night.

A youtube video by GloriousEggroll who gets it working on Arch.

Haven't tried it yet, but it seems to work (for now).

Addition : Tested it, wand it works! This also fixes the dead island games for me.

Summary : compile mesa with GLVND DISABLED and use the resulting libs via LD_LIBRARY_PATH as not to mess with with your installed mesa.

glvnd is the issue it seems.

Hello, thanks for the timely information, you can share the two mentioned libraries, to use as a type of dll in ubuntu.

as GloriousEggroll says in this post;

https://www.reddit.com/r/linux_gaming/comments/9jd2y0/how_to_play_dying_light_in_arch_linux/e6rloy0/

Hey so I had a crack at this and took it a bit further!

I followed your directions, then when I got the game running, I looked at the Library usage in the task manager to find out what specific libraries it was using from the specified library path:

/run/media/Storage/Projects/Development/OS/mesa/AUR/mesa-git/pkg/mesa-git/usr/lib/libGL.so.1.2.0

/run/media/Storage/Projects/Development/OS/mesa/AUR/mesa-git/pkg/mesa-git/usr/lib/libglapi.so.0.0.0

so I copied just those two inside my Dying Light install on steam, then set launch options:

LD_PRELOAD=$LD_PRELOAD:libGL.so.1.2.0:libglapi.so.0.0.0 %command%

sure enough it booted without any problems.

So I took it further and re-added Arch's default compiler arguments, and compiled again without glvnd, then repeated the same steps. Game booted!

I would appreciate if you can upload those two libraries in a folder bought some server.

I cannot share the libraries because they need to be compiled with the version of LLVM that exists on the system they are being used on. Also, I am not going to maintain and update the libraries every time a new version of llvm or mesa comes out. This fix is a workaround for Arch until the problem is resolved with glvnd. Also sharing compiled binaries is not secure.

I cannot share the libraries because they need to be compiled with the version of LLVM that exists on the system they are being used on. Also, I am not going to maintain and update the libraries every time a new version of llvm or mesa comes out. This fix is a workaround for Arch until the problem is resolved with glvnd. Also sharing compiled binaries is not secure.

Hello, following the recommendations of GloriousEggroll, I decided to try it in my distro kubuntu 18.04, after many failed attempts and about to give up, I found the golden egg.

based on these two guides, I got the solution.

"https://www.gamingonlinux.com/wiki/Building_Mesa_from_source"
"https://xorg-team.pages.debian.net/xorg/howto/build-mesa.html"

*only 64 bits
*You must use one of the two PPAs, Oibaf (mesa 18.3-devel with llvm 7) or Padoka Stable (mesa 18.2.1 with llvm 7), for AMD Graphics card, I use Oibaf for the moment.

1º Open terminal or konsole, we must install what is necessary for the compilation (for command "build-dep mesa" you must enable deb-src in the repository list of the PPA that you choose to use).
sudo apt-get install build-essential git libelf-dev libsdl2-2.0 llvm-7 llvm-7-dev
sudo apt-get build-dep mesa

2º well we continue working with our current terminal or konsole and we will add these necessary parameters, one by one.
build_dir="${HOME}/build/mesa"
cpuarch="znver1" # I set it for Zen, but you can use "native" or anything else you like.
build_threads=$(nproc)
arch_dir["32"]="x86"
arch_dir["64"]="x86_64"
arch_vk["32"]="i686"
arch_vk["64"]="x86_64"

mkdir -p "$build_dir"
cd $(dirname "$build_dir")

git clone git://anongit.freedesktop.org/mesa/mesa $(basename "$build_dir")
cd "$build_dir"
autoreconf -vfi

3º We continue in our current terminal or konsole, once the task of "autoreconf -vfi" finalized, continue with the variants for "./configure", GLVND is not mentioned because it is disabled by default, the location of llvm 7 can be changed here "--with-llvm-prefix=/usr/lib/llvm-7/".
./configure --build=x86_64-linux-gnu --prefix=${mesa_dir} --includedir=\${prefix}/include --mandir=\${prefix}/share/man --infodir=\${prefix}/share/info --sysconfdir=/etc --localstatedir=/var --disable-silent-rules --libdir=\${prefix}/${arch_dir["64"]} --libexecdir=\${prefix}/${arch_dir["64"]} --disable-maintainer-mode --disable-dependency-tracking --enable-dri "--with-dri-drivers= i965" --with-dri-driverdir=/usr/lib/x86_64-linux-gnu/dri --with-dri-searchpath=/usr/lib/x86_64-linux-gnu/dri:\\\$\${ORIGIN}/dri:/usr/lib/dri "--with-vulkan-drivers= intel radeon" --enable-osmesa --enable-glx-tls --enable-shared-glapi --enable-texture-float --disable-xvmc --disable-omx-bellagio --enable-driglx-direct --enable-gbm --enable-dri3 "--with-platforms=x11,surfaceless wayland drm" --enable-xa --enable-llvm --enable-opencl --enable-opencl-icd --with-llvm-prefix=/usr/lib/llvm-7/ --enable-vdpau --enable-va --enable-gallium-extra-hud --enable-lmsensors "--with-gallium-drivers= radeonsi" --disable-gles1 --enable-gles2 "CFLAGS=-g -O3 -fdebug-prefix-map=${HOME}/build=. -march=${cpuarch} -fstack-protector-strong -Wformat -Werror=format-security -Wall" "CPPFLAGS=-Wdate-time -D_FORTIFY_SOURCE=2" "CXXFLAGS=-g -O3 -fdebug-prefix-map=${HOME}/build=. -march=${cpuarch} -fstack-protector-strong -Wformat -Werror=format-security -Wall" "FCFLAGS=-g -O3 -fdebug-prefix-map=${HOME}/build=. -fstack-protector-strong" "FFLAGS=-g -O3 -fdebug-prefix-map=${HOME}/build=. -march=${cpuarch} -fstack-protector-strong" "GCJFLAGS=-g -O3 -fdebug-prefix-map=${HOME}/build=. -fstack-protector-strong" LDFLAGS=-Wl,-z,relro "OBJCFLAGS=-g -O3 -fdebug-prefix-map=${HOME}/build=. -march=${cpuarch} -fstack-protector-strong -Wformat -Werror=format-security" "OBJCXXFLAGS=-g -O3 -fdebug-prefix-map=${HOME}/build=. -march=${cpuarch} -fstack-protector-strong -Wformat -Werror=format-security"

4º If you have succeeded with "./configure", proceed with our beloved "make" that will give us the golden egg, write in your current terminal or konsole, armed with patience go for some snacks!.
make

5º finally we have the golden egg, finished the task of "make" if you have not had errors we will close our current terminal or konsole and go to the folder that we have created "/ home / your user / build / mesa / x86_64 /" and copy two files "libGL.so.1.2.0 and libglapi.so.0.0.0" in the steam installation folder of "Dying Light", once that is done we will open Steam and in the launch options we will add the command.
LD_PRELOAD=$LD_PRELOAD:libGL.so.1.2.0:libglapi.so.0.0.0 %command%

Press play!! and to have fun :D :3

I hope to help those who use distros based on deb, greetings from Chile thanks to all, hopefully Techland repair this soon.(it's 05:00 AM I want to sleep u-u)

P. D. Sorry for my English.

@schidin you probably want to be on llvm 7 or llvm-svn. llvm 6 is well known for hard gpu hangs in various games. once you upgrade llvm you will also have to compile + install mesa-git + lib32-mesa-git. Please note that you should turn ON glvnd (set glvnd=true) before installing mesa-git. You only need to turn it off for the Dying Light libraries, which dont work system wide (which is why we dont install the package with glvnd disabled).

Note: a lot of people dont understand that mesa has to be compiled with whatever version of llvm is on the system. so when you reinstall llvm, you also have to recompile mesa so that it uses that llvm version

what I dont understand is, that before I began trying to fix Dying Light, I didnt even have LLVM installed. I only installed this package after I saw Your video where it was needed to build MESA. But MESA was already installed on my system (and I played a lot of games without issues). So I just wondered about the whole LLVM-problem...

I bet you did have libllvm though as it's a Mesa dependency. On Ubuntu 18.04 or Mint 19 you'd get libllvm6.0 installed by default.

EDIT: I did notice you run Manjaro. The package might be llvm-libs there?

i have compiled Mesa 18.2.1 with LLVM 6.0.0 on Ubuntu 18.04 with glvnd disabled. Dying Light wont start. you must compile with llvm 7 or svn to avoid GPU hang.

i have do some tests with my "home compiled" Mesa 18.2.1

some game will start like tomb raider, day of infamy, serious sam 3 bfe

verdun or shadow of mordor dont start.

i have compiled Mesa 18.2.1 with LLVM 6.0.0 on Ubuntu 18.04 with glvnd disabled. Dying Light wont start. you must compile with llvm 7 or svn to avoid GPU hang.

i have do some tests with my "home compiled" Mesa 18.2.1

some game will start like tomb raider, day of infamy, serious sam 3 bfe

verdun or shadow of mordor dont start.

hello, I do not understand your information, the compilation of "Mesa" is only to get two files for dying light not for the root system, if you want llvm 7 use padoka stable ppa and compile with that as described on page 14, if you use ubuntu 18.04.

the only mistake I've had, when using the "Drop Attack" skill closes the game randomly, I already sent a ticket to Techland, I played several hours without any crashes.

I cannot share the libraries because they need to be compiled with the version of LLVM that exists on the system they are being used on. Also, I am not going to maintain and update the libraries every time a new version of llvm or mesa comes out. This fix is a workaround for Arch until the problem is resolved with glvnd. Also sharing compiled binaries is not secure.

I agree that everyone should be very careful when using shared objects downloaded from the web, but I think that we can believe on each other here... for now.

In the other hand, as the problem seems to be related with glvnd (which, AFAIK, is an standard way for supporting multiple OGL vendors implementations) we will not get in to LLVM version problems as it is used by the dri drivers. In other words: if replacing libGL.so and libglapi.so does the trick, then sharing this two files should be a workaround for everyone that is using the same base distro no matter the llvm version.

Either case, good catch with glvnd. I recently discovered that a local default Mesa drivers build was working and Padoka's versions were crashing the game. GLVND really fits as the source of the problem as a default meson build on mesa has glvnd disabled. Good to see that the community dig out the reason of DIDE & DL crash.

I agree that everyone should be very careful when using shared objects downloaded from the web, but I think that we can believe on each other here... for now.

In the other hand, as the problem seems to be related with glvnd (which, AFAIK, is an standard way for supporting multiple OGL vendors implementations) we will not get in to LLVM version problems as it is used by the dri drivers. In other words: if replacing libGL.so and libglapi.so does the trick, then sharing this two files should be a workaround for everyone that is using the same base distro no matter the llvm version.

Either case, good catch with glvnd. I recently discovered that a local default Mesa drivers build was working and Padoka's versions were crashing the game. GLVND really fits as the source of the problem as a default meson build on mesa has glvnd disabled. Good to see that the community dig out the reason of DIDE & DL crash.

Hi, I share your opinion, if you're interested I uploaded the "Libs" for you to try, they are compiled with llvm 7 in a Ryzen 1600, I also uploaded the last Kernel in the branch 4.18.8 based on amd-staging-drm-next, it is a delight for those who use AMDGPU, all this I use in conjunction with Obaf ppa or Padoka Stable.

Only for Ubuntu 18.04 64 bits

Dying Light Libs
https://drive.google.com/file/d/12enZT4pLIH59HN7zdmwqup1PI0mD_m8a/view?usp=sharing

Kernel 4.18.8 based on amd-staging-drm-next
https://drive.google.com/file/d/1jMeMc7hpzkd-6mRSLQU2zhHIZ12h8ddc/view?usp=sharing

from https://github.com/M-Bab/linux-kernel-amdgpu-binaries (they are currently in branch 4.19.0 RC6, I'm waiting for the final version)

I agree that everyone should be very careful when using shared objects downloaded from the web, but I think that we can believe on each other here... for now.

In the other hand, as the problem seems to be related with glvnd (which, AFAIK, is an standard way for supporting multiple OGL vendors implementations) we will not get in to LLVM version problems as it is used by the dri drivers. In other words: if replacing libGL.so and libglapi.so does the trick, then sharing this two files should be a workaround for everyone that is using the same base distro no matter the llvm version.

Either case, good catch with glvnd. I recently discovered that a local default Mesa drivers build was working and Padoka's versions were crashing the game. GLVND really fits as the source of the problem as a default meson build on mesa has glvnd disabled. Good to see that the community dig out the reason of DIDE & DL crash.

Hi, I share your opinion, if you're interested I uploaded the "Libs" for you to try, they are compiled with llvm 7 in a Ryzen 1600, I also uploaded the last Kernel in the branch 4.18.8 based on amd-staging-drm-next, it is a delight for those who use AMDGPU, all this I use in conjunction with Obaf ppa or Padoka Stable.

Only for Ubuntu 18.04 64 bits

Dying Light Libs
https://drive.google.com/file/d/12enZT4pLIH59HN7zdmwqup1PI0mD_m8a/view?usp=sharing

Kernel 4.18.8 based on amd-staging-drm-next
https://drive.google.com/file/d/1jMeMc7hpzkd-6mRSLQU2zhHIZ12h8ddc/view?usp=sharing

from https://github.com/M-Bab/linux-kernel-amdgpu-binaries (they are currently in branch 4.19.0 RC6, I'm waiting for the final version)

Sorry I didn't answer you before. Unfortunately your .so doesn't work for me, most probably because you compiled your version optimized for your CPU (I have an Intel 3570k, while you have a Ryzen which probably have a more advanced instruction set that is used in the .so -- I get an ilegal instruction error). Anyway, by doing the preloading of libGL.so (yep, only that shared object) that I have built locally (Mesa defaults) I was able to run DL using all the other shared objects of Padoka Stable.

In case anyone want to test with my build, I leave a copy of my libGl.so here: https://drive.google.com/file/d/1Lb206FtWBNnL4MHBSBm0N3drmHojDCel/view?usp=sharing

To test it, just unpack the file and add as game launch option of DL/DIDE: LD_PRELOAD=/PATH_WHERE_UNPACKED_THE_TAR_GZ/libGL.so.1.2.0 %command%

I tested it with Padoka stable and works fine. It may work with the Unstable version, but I can't guarantee that.

Is there a way the developer Techland can fix this by default? Maybe we should inform them about this.

As somebody else mentioned in the thread, we should report problems here: http://dyinglight.support.techland.pl/en/support/solutions/articles/15000009911--ubuntu-steamos-variables-with-hardinfo-and-crash-logs

Anyway, I just send a message with our findings. Hope they can make a fix for this.

Alright, here my fix...

My system is a ryzen 5 2600x, 16GB ram, with a amd r9 fury, using the amdgpu all open driver(which provides mesa 18.1.0-rc4) provided on their website here. USE THE ALL OPEN VARIANT as the Pro driver performs poorly, 30fps vs 70fps plus. You will still need to use the steam properties argument "MESA_GL_VERSION_OVERRIDE=4.5 MESA_GLSL_VERSION_OVERRIDE=450 %command%" as it will crash without it.

Hey so I found placing the libGL.so.1 directly into the Dying Light folder makes it so you don't need LD_PRELOAD or any Launch options (w/ Mesa 18.2+) which also gave me back the Steam Overlay as the overlay wasn't working using that Launch option. I also went and grabbed libGL.so.1 directly from the SteamOS Repo but I have no idea which version would actually be the best, just seems as long as it's libGL.so.1.2.0. I tested the libgl1-mesa-glx .deb directly from Ubuntu 14.04 (Dying Lights System Requirements) and that one works as well.

Here's a copy & paste code to download the libgl1-mesa-glx .deb file from the SteamOS Repo, extract and move libGL.so.1.2.0 to the default Steam install (~home steamapps) folder for Dying Light as libGL.so.1 and then remove the folder created by the extract and the downloaded .deb file.

wget http://repo.steampowered.com/steamos/pool/main/m/mesa/libgl1-mesa-glx_13.0.2-3+bsos1_amd64.deb
dpkg-deb -R libgl1-mesa-glx_13.0.2-3+bsos1_amd64.deb libgl1-mesa-glx_13.0.2-3+bsos1_amd64
mv libgl1-mesa-glx_13.0.2-3+bsos1_amd64/usr/lib/x86_64-linux-gnu/libGL.so.1.2.0 ~/.steam/steam/steamapps/common/Dying\ Light/libGL.so.1
rm -R libgl1-mesa-glx_13.0.2-3+bsos1_amd64 libgl1-mesa-glx_13.0.2-3+bsos1_amd64.deb

This works from a fresh install of Dying Light on Ubuntu 18.10 with no Launch options or PPA using Mesa 18.2.2.
I've found performance to be pretty much on par with Windows from what I recall and I tested for about an hour with no issues.
RX 580 with only the open source Mesa driver installed, no AMDGPU software. Ryzen 2600X with nothing added to Ubuntu 18.10.

Maybe all Techland would have to do is include the required version of libGL.so.1 as they already include several other .so files inside the Dying Light install folder.

Does the above fix work on Manjaro and other distros?

The GOG Windows build works in wine_staging+dxvk at 75 fps on a 75 Hz monitor with vsync. :)

I have the RX 580, Ryzen 1700 and latest mesa drivers from the Manjaro repos.

The Bronx workaround works fine. The performance is good here with Ubuntu 18.10 /RX480 LLVM7/Mesa 18.2.2

Hi sorry, here's the copypasta that should be cross distro.
I just replaced dkpg-deb with ar and tar commands, please correct me if there's a better way.
-Oh yeah and if you don't have wget installed you can just download the .deb with your browser and run the rest of the commands from the Downloads folder where the .deb is located.

wget http://repo.steampowered.com/steamos/pool/main/m/mesa/libgl1-mesa-glx_13.0.2-3+bsos1_amd64.deb
ar x libgl1-mesa-glx_13.0.2-3+bsos1_amd64.deb data.tar.xz
mkdir libgl1-mesa-glx
tar -xf data.tar.xz -C libgl1-mesa-glx
mv libgl1-mesa-glx/usr/lib/x86_64-linux-gnu/libGL.so.1.2.0 ~/.steam/steam/steamapps/common/Dying\ Light/libGL.so.1
rm -R libgl1-mesa-glx data.tar.xz libgl1-mesa-glx_13.0.2-3+bsos1_amd64.deb

Be to sure to alter the mv command (5th line) to point to your steamapps/common/Dying Light location if it's different from the default (~home/steam).

libGL.so.1.2.0 only fixes the "Caught signal 11 (Segmentation fault)" crash after the first loading bar.
~/.steam/steam/steamapps/common/Dying Light/DW/out/logs/crash*.log
You'll still need the Mesa GL Version Override Launch option if you're not running Mesa 18.2+.

Thanks for this. I'll make sure to test it tonight and get back with feedback. It would be great if we could run the game natively with decent performance. :)

Later edit: Yup. It works. :D

I simplified the process and uploaded the specific file you need so all people have to do it's just extract this file into the dying light folder.
https://drive.google.com/open?id=1WC9pDLgY-pC8M9c8Pl8ft-6dx1PBfk7m

I simplified the process and uploaded the specific file you need so all people have to do it's just extract this file into the dying light folder.
https://drive.google.com/open?id=1WC9pDLgY-pC8M9c8Pl8ft-6dx1PBfk7m

Thanks !

This fix works on Arch! Cheers.