Dying Light not working via Arch AUR package, works via snap, problem with libc

[GloriousEggroll]

Hi. I managed to get Dying Light to run via the snap package on Arch, but I was unable to get it running on the Arch AUR package due to a segmentation fault with libc. I feel this is because the snap package uses solus runtimes which include glibc, where the Arch package does not, and Arch's native glibc causes the crash. Rolling back the Arch package did not resolve the issue. I do realize this may be an issue related to Arch, and not this project, just posting in case there is some workaround. If not feel free to close. Dying Light does not play friendly with Arch's version of glibc. Error log:

{17:01:09.380} INFO: [INFO] > Caught signal 11 (Segmentation fault).
{17:01:09.382} INFO: [INFO] > /usr/lib/libc.so.6(+0x34920) [0x7f13d3090920]

[ikeydoherty]

We sure this is libc itself and not caused higher up by a bug in another package? Might be worth using gdb here :]

[GloriousEggroll]

not sure how to use gdb with steam tbh, however there is an ongoing thread about it here:
https://www.gamingonlinux.com/index.php?module=viewtopic&topic_id=2766&page=5

here is my most recent full crash log from dying light's game log folder:
http://ix.io/Dg1

game runs fine in the snap, but the AUR version of LSI without snap has the same crash as normal steam on arch.

[John-Gee]

I have the same issue :)

The gdb log does not seem very interesting:
https://gist.github.com/John-Gee/4257f70e27854e87f3b8fd6dd079793c

[ikeydoherty]

@GloriousEggroll btw your reasoning on your post is incorrect

"The reasoning behind this is that the snap uses ubuntu backend libraries."

It actually doesn't, it only uses Solus libraries :)

[GloriousEggroll]

woops! I'd written the blog post before i knew about the runtimes being from solus (as my issue here mentions solus runtimes but blog mentions ubuntu). I've corrected! Thanks again for your work on this

[ikeydoherty]

No worries :D Do we know what their glibc is doing differently, then?

It is also possible somehow our glibc build is masking some issue because we enable AVX variants?

You can have a dig here if you can find anything! https://github.com/solus-project/runtime-snaps/tree/master/support_packages/glibc

[skyrrd]

i have glibc built with avx & avx2 (gentoo with avx avx2 ... cpu_flags) but that doesn't fix the issue for me

i'm running against a wall here:

{23:27:04.794} INFO: [INFO] > [OpenGL] Video memory detected: 0 [MB]!
{23:27:04.797} INFO: [INFO] > Caught signal 11 (Segmentation fault).
[...]
{23:27:04.794} INFO: [INFO] > [OpenGL] Video memory detected: 0 [MB]!
{23:28:11.741} INFO: [INFO] > Caught signal 2 (Interrupt).

Bug is known and closed as it "only affects lesser used distros" source

[skyrrd]

does your steam integration (as snap package) install a user-accessable lspci?
On many distributions lspci is located in /usr/sbin/ and is not found by normal user / programs
after creating a symlink "ln -s /usr/sbin/lspci /usr/bin/lspci" I am able to play Dying Light on Gentoo Linux and i suppose that will work on other distributions as well.

[ikeydoherty]

Yep lspci is in normal user path

[kaymio]

As a fellow Arch user I followed the little tutorial from @GloriousEggroll and it finally became relatively playable. Recently some update (snapd-git, mesa?) broke the game again. As my friends urge me to get this fixed I installed Solus on a second SSD. Solus looks nice, feels snappy but isn't for me in the long run as its repos don't even come close to the Arch repos + AUR.
Neither an install with the steam package from the Solus repos, nor this snap fixed the issue on my machine. (990X + 8320e + RX480)

ERROR: ld.so: object '/home/gamer/snap/linux-steam-integration/common/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so' from LD_PRELOAD cannot be preloaded (wrong ELF class: ELFCLASS32): ignored. GameAction [AppID 239140, ActionID 4] : LaunchApp changed task to Completed with "" /home/gamer/snap/linux-steam-integration/common/.local/share/Steam/steamapps/common/Dying Light/DyingLightGame: /usr/lib/libcurl-gnutls.so.4: no version information available (required by libengine.so)

Nonetheless I would consider a dualboot if I got this game finally to run (relatively) reliable.

Could you please fix it?

I get more output from the snap console when using OpenGL4.4 as start option.
DLwOpenGL4.4.txt

And here is the console output from snap on Arch with different errors.
DLArch_oGL4.4.txt

[GloriousEggroll]

@kaymio -edit-

updated snapd-git today. game launches and runs, but freezes.

-edit 2-
changed overrides from
MESA_GL_VERSION_OVERRIDE=4.4 MESA_GLSL_VERSION_OVERRIDE=440 %command%
to
MESA_GL_VERSION_OVERRIDE=4.5 MESA_GLSL_VERSION_OVERRIDE=450 %command%

game's running so far without a hitch. I wonder if the override needs to match mesa's core profile

NOTE: Still does not run when launched from arch's linux-steam-integration package. gives white loading bar then konks out, only runs via snap.

asus strix x370+r7 1700x+vega 64

[GloriousEggroll]

as of today looks like it's broken again. seems recent update to libc caused it to now have the same problem arch does:

{18:58:13.457} INFO: [INFO] > Caught signal 11 (Segmentation fault).
{18:58:13.458} INFO: [INFO] > /usr/lib/libc.so.6(+0x36570) [0x7f4900337570]
{18:58:13.458} INFO: [INFO] | libengine.so(_ZN12CTextManager10InitializeEv+0x26f) [0x7f4901d150cf]
{18:58:13.458} INFO: [INFO] | libengine.so(_Z13CreateTextMgrv+0x40) [0x7f4901d15220]
{18:58:13.458} INFO: [INFO] | libengine.so(_ZN9CRenderer13LoadResourcesEv+0x2c) [0x7f4901d0287c]
{18:58:13.458} INFO: [INFO] | libengine.so(_ZN5CGame10InitializeEPciPvS1_jjP18IProgressIndicator+0x1944) [0x7f49017da8b4]
{18:58:13.458} INFO: [INFO] | /home/gloriouseggroll/snap/linux-steam-integration/common/.local/share/Steam/steamapps/common/Dying Light/DyingLightGame(main+0xa45) [0x43e315]
{18:58:13.458} INFO: [INFO] | /usr/lib/libc.so.6(__libc_start_main+0xea) [0x7f490032153a]
{18:58:13.458} INFO: [INFO] | /home/gloriouseggroll/snap/linux-steam-integration/common/.local/share/Steam/steamapps/common/Dying Light/DyingLightGame() [0x4425d9]

I uninstalled solus-runtime-gaming and linux-steam-integration, then downloaded the older versions from here:

https://packages.solus-project.com/lsi/8/
and installed them, and the game ran again

[kaymio]

Quite a hassle to go through. This was the only game that I did dual boot for. After trying my dear Arch and Solus, I chose to go with the "officially supported" Linux distribution Ubuntu. I started with 17.10, went to 18.04 beta, which both didn't work. Finally tried 16.04 by chance, months later and it simply worked. Since then I have a distro running for one game. I had/have high hopes in Solus to become my stable, rolling release, desktop and gaming distro, especially with snap, but more so with flatpak support ;) While Arch remains my playground.

Thank you for your effort, but without the attention and interest of the DL devs this game will never run smoothly with RX480 mesa graphics on other distros, not even 17.10 and 18.04.

[GloriousEggroll]

@ikeydoherty do you happen to know what version of libglvnd was used for these?
https://packages.solus-project.com/lsi/8/

it was recently discovered the cause behind Dying Light being broken is libglvnd, but in older versions it worked. it probably needs a bisect starting from the working version in the runtimes listed above

[John-Gee]

I've tried with v1, but it wasn't any better. I haven't tried with the previous one so who knows, but with that LSI being post v1 release I'd guess it's using it or newer.

[GloriousEggroll]

I double checked the solus mesa scripts, turns out the old runtime used a custom version of mesa, which did not use glvnd :
solus-project/runtime-snaps@4e1fd0f#diff-43a8a572e06eb29c6a8b39a8d152937f

this was then replaced with the solus OS default mesa package, which did have it enabled (line #87):
https://dev.getsol.us/source/mesalib/browse/master/package.yml

which is why it broke in the solus snap.

this leads me to believe that it never worked.

I've posted this same comment over at the glvnd issue tracker

[John-Gee]

That would be my guess as well.