Great news: i managed to get Dying Light to work on Gentoo Linux without snapd or similar soulutions ;)



will write down later what i have done to get it working (not everything i have done is needed i suppose ;))

Ok Guy here's the solution to get Dying Light running on Gentoo (didn't have time to check any other distro now) and it's disappointingly simple =)

What i was trying the all the time was getting the library-issues fixed including libcurl-gnutls, libdap, librtmp and so on.
After hunting down all these library dependencies the game still crashed.
In the logs i found out it didn't detect any video memory.

Thing is Dying Light uses lspci to detect your Graphics Card (at least when running on mesa).
Since on most distributions this binary is located in /usr/sbin/ the game can't find it and reports no video memory and crashes.

All i did was creating a symlink "ln -s /usr/sbin/lspci /usr/bin/lspci" and the game would start up fine, even without fixing the library dependencies

HOLY CRAP! skyrrd !

Is that what I was missing after all of this time?
A bigger question: how did you come across this?

+
Its a good find but Ubuntu/Mesa for me in some logs
I posted months ago also reported zero video memory.
It might be a case where the game doesn't use the
output of video memory from lspci.

It doesn't work on Arch.

ln -s /usr/sbin/lspci /usr/bin/lspci
ln: failed to create symbolic link '/usr/bin/lspci': File exists

Can you execute lspci as normal user?
Could you post the permissions of your lspci?

So i guess i'll setup arch in the days ahead and take a closer look ;-)

Next point of interest would be glibc (guess it needs avc2 optimization) and i don't know if thats the case with arch.

Guess we needs some list oft what are the global requirements and what distros needs what Operation to fix this.

WOW! Techland could've help us out with this
a long time ago, if they gave a damn.

Can you execute lspci as normal user?

Yep. I get a lot of lines regarding my AMD RX 580 GPU.

On what Version of mesa is antergos now? Would maybe take a look later in a live-session.

Yes i think it would have been an relativly easy task to support mesa but to be fair, the mesa-graphics stack wasn't as polished when the game was released on linux as it is now.

But hey, there are not many major distributions now that don't support snap packages so the chances you can play the game with mesa are quite gold right now ;-)

Quoting: skyrrdOn what Version of mesa is antergos now? Would maybe take a look later in a live-session.

17.3.1-2
Antergos uses almost entirely the same packages as Arch.

good, will give it a shot later. should feel right at home since i've been a long-time arch-user before switching to gentoo.

But not before wife and kid are asleep...and that could take a while ;)

Thanks for the help. Appreciate it. :)

Had some issues yesterday with cnchi installer not passing "preparing disks". I'll take a look when i have some spare time but no promise when ;-)

Quoting: devlandIt doesn't work on Arch.

ln -s /usr/sbin/lspci /usr/bin/lspci
ln: failed to create symbolic link '/usr/bin/lspci': File exists

There's no need on arch to do this anyway. if you do ls -l / you'll see why.

bin -> usr/bin
lib -> usr/lib
lib64 -> usr/lib
sbin -> usr/bin

In other words sbin and bin are already pointing to the same location.

I'm now testing on Antergos (got the installer issue sorted out).
The game crashes after loading screen, log is hinting towards libc.so.6 so i'm now compiling an avx2 optimized glbic from aur and test if that fixes the problem

OK sadly simply enabling avx and avx2 with cflags and cpuflags in makepkg.conf and then compiling glibc-git with yaourt did not work either. If i'm doing sth wrong please correct me ;-)

No idea. I was trying to import the dependencies from the solus snap packages based on what ldd lists.

I'm glad it works for you as well ;-)

It would be awesome to know what really makes the difference.
AS we already know it can be played on arch, fedora, etc with snap package and now ubuntu (at least some versions), solus OS, Debian testing and gentoo without needing snap. I'll do some further testing with diffenrent distributions when i have some more time for some sort of compatibility-list.

Well, I got it to work on arch with the snap version of steam from the solus guys. but not with the lsi-steam from AUR. I might be missing the point of the lsi package.
Funny, this makes me even more annoyed at the fact that it won't run on my arch installation without the snaped steam.

I'm curious to know what @skyrrd finds out is the real issue here. I've been chasing the same path but gave up at some point.

I tried xubuntu 16.04 this past weekend and didn't manage to start it from the console with Steam on. It only started from steam. I got the "failed to start renderer" error when trying to start it via console. I get the same error on Antergos after copying over all the required dependencies from the solus snaps. My guess is that Steam does some extra runtime variable setting that we are missing.

The next thing I want to try is to monitor the game process while it's working inside the solus snaps and inspect the full console command used by steam to start it. And then mimic it to start it manually without the snaps and with all the dependencies copied over from them.

Pls find a workaround, same thing happens to me, Archlinux kernel 4.14.12 mesa 17.3.1 with amd gpu (core opengl 4.5), many users over the internet are having the same luck with opensuse distros and dying light.I've played a couple of dozen of games in steam and dying light is the only one that doesnt launch.