You can sign up to get a daily email of our articles, see the Mailing List page!
Support us on Patreon to keep GamingOnLinux alive. This ensures we have no timed articles and no paywalls. Just good, fresh content! Alternatively, you can donate through Paypal, Flattr and Liberapay.!
  Go to:
[Fixed, needs testing] Dying Light refuses to launch
skyrrd commented on 23 September 2017 at 10:05 am UTC

wow thank you very much for your help.
i didn't realize that i haven't checked this thread for so long.

blendi-93i had the same issue, to fix it i emerged steam-meta and run it.
steam meta installed and downgraded some packages (including glew) this fixed it for me.
what overlay are you using for steam?
what versions did you downgrade "some packages" to?

sr_ls_boyI'm not using gentoo. I don't really know what steam-meta is. Is it the steam bootstrapper?
Is it an executable? Is it a set of system libraries?

'skyrrd' if you do follow this hint, make note of which libraries are installed when emerging.

I ran this inside the DL game folder:
find -name "*.so" -exec ldd {} \; | grep not | sort -u
Then I just pulled some libraries from the steam runtime and placed in my system folder.
That allowed me to run the game without using steam runtime but it didn't fix the crash.

Your script points at, so nothing really new but i will try to pull that one from runtimes and try to launch the game with system runtimes.

You could say meta-packages install the base-packages + some usefull or required additions.

stan commented on 23 September 2017 at 10:50 am UTC

For me Dying Light works on Gentoo stable if I set STEAM_RUNTIME_PREFER_HOST_LIBRARIES to 0, but I’m using the nvidia blob, so I guess it doesn’t apply to mesa users… I’m using the "steam-launcher" package from the "steam-overlay" overlay, with the steamruntime flag enabled.

skyrrd commented on 23 September 2017 at 10:59 am UTC

I thought STEAM_RUNTIME_PREFER_HOST_LIBRARIES=0 was the default behavior? Or did that change lately?
Anyways. Might give it a shot as well;-)

devland commented on 26 September 2017 at 12:23 pm UTC

Did anyone manage to get it working on AMD with mesa?
This appears to be an AMD GPU only issue that happens only on mesa. From what I've managed to search online, it works if you use amdgpu-pro.

sr_ls_boy commented on 26 September 2017 at 2:10 pm UTC

Since I have been here I have a new Ryzen based build. I also built a Cross-LFS with
glibc 2.25 linux install, from the ground up. Nothing has changed for me. Those, using
source based distros sans systemd, who cannot get the game to work probably never will.

There is something odd going on here and we are getting no help from Techland.

QuoteYour script points at


EDIT: Oh, I see now.
I get it too. I have curl & gnutls but not both together in one library.
Also have version conflicts with libpng.

On the other hand, I keep an Ubuntu install allways handy. The game works with Ubuntu/Mesa.
But I encountered some graphical gitches with the main menu that I shut the game down.

skyrrd commented on 26 September 2017 at 3:27 pm UTC

Just some update: when starting steam without steam-runtime (installed or copied all necessary libraries) i dont get an library error with dying light but something about x window error

Everything else that i tried since works with this setup (e.g. deus ex, tomb raider, black mesa, etc...)

I hope i can track down the issue any further.

sr_ls_boy commented on 26 September 2017 at 5:30 pm UTC

GDB might help. I tried to runt the game without the steam runtime. It
started several threads that I don't know how to hook in to.

Can anyone give a quick primer in tracing a process that starts multiple

sr_ls_boy commented on 26 September 2017 at 6:27 pm UTC

This is my first backtrace. It just mirrors what is in my dying light logs.
pthread_join.c:45 is a part of glibc sources.

Spoiler, click me

#0 __lll_lock_wait () at ../sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:135
#1 0x00007fe33f0d9d05 in __GI___pthread_mutex_lock (mutex=mutex@entry=0x7fe326a37ca0 <exit_mutex>) at ../nptl/pthread_mutex_lock.c:80
#2 0x00007fe32636f5b5 in mtx_lock (mtx=0x7fe326a37ca0 <exit_mutex>) at ../../../include/c11/threads_posix.h:227
#3 remove_from_atexit_list (queue=0x161e1e0) at ../../../src/util/u_queue.c:78
#4 util_queue_destroy (queue=queue@entry=0x161e1e0) at ../../../src/util/u_queue.c:300
#5 0x00007fe3264815bd in tc_destroy (_pipe=0x161de10) at ../../../../src/gallium/auxiliary/util/u_threaded_context.c:2235
#6 0x00007fe326280024 in st_destroy_context_priv (st=st@entry=0x1636c80, destroy_pipe=destroy_pipe@entry=true) at ../../../src/mesa/state_tracker/st_context.c:283
#7 0x00007fe326280508 in st_destroy_context (st=0x1636c80) at ../../../src/mesa/state_tracker/st_context.c:642
#8 0x00007fe3263ec1cd in dri_destroy_context (cPriv=<optimized out>) at ../../../../../src/gallium/state_trackers/dri/dri_context.c:215
#9 0x00007fe3263eb333 in driDestroyContext (pcp=0x16144a0) at ../../../../../../src/mesa/drivers/dri/common/dri_util.c:506
#10 0x00007fe3374debcf in dri3_destroy_context (context=0x1645780) at ../../../src/glx/dri3_glx.c:206
#11 0x00007fe3374b6d3a in glXDestroyContext (dpy=0x1470c70, ctx=0x1645780) at ../../../src/glx/glxcmds.c:474
#12 0x00007fe33ee7a4bd in X11_GL_DeleteContext (_this=<optimized out>, context=<optimized out>) at /home/a_jagers/Downloads/SDL2-2.0.6/src/video/x11/SDL_x11opengl.c:936
#13 0x000000000048f20a in SDL:estroy() ()
#14 0x000000000048f259 in SDL::~SDL() ()
#15 0x000000000044279c in SignalCallbackHandler(int) ()
#16 <signal handler called>
#17 pthread_join (threadid=140613379299072, thread_return=thread_return@entry=0x7ffef7fc7c28) at pthread_join.c:45
#18 0x00007fe32636f120 in thrd_join (res=0x0, thr=<optimized out>) at ../../../include/c11/threads_posix.h:336
#19 util_queue_killall_and_wait (queue=queue@entry=0x151d418) at ../../../src/util/u_queue.c:292
#20 0x00007fe32636f178 in atexit_handler () at ../../../src/util/u_queue.c:51
#21 0x00007fe33773c6c0 in __run_exit_handlers (status=1, listp=0x7fe337aa45d8 <__exit_funcs>, run_list_atexit=run_list_atexit@entry=true, run_dtors=run_dtors@entry=true) at exit.c:83
#22 0x00007fe33773c71a in __GI_exit (status=<optimized out>) at exit.c:105
#23 0x00007fe31190a00c in ?? ()
#24 0x0000000000000000 in ?? ()

This is the matching source lines from the frames leading up to the seg fault.
I compiled glibc-2.25 & mesa 17.2.1 from the tarballs with debugging symbols.
Spoiler, click me

Frame #16 <signal handler called>

1│ Dump of assembler code for function __restore_rt:
2├──> 0x00007fe337739a90 <+0>: mov $0xf,%rax
3│ 0x00007fe337739a97 <+7>: syscall
4│ 0x00007fe337739a99 <+9>: nopl 0x0(%rax)
5│ End of assembler dump.


if (pthread_join(thr, &code) != 0)

thrd_join(queue->threads[i], NULL);


cxafct (f->func.cxa.arg, status);

__run_exit_handlers (status, &__exit_funcs, true, true);

skyrrd commented on 26 September 2017 at 7:57 pm UTC

To be honest i have no idea what i should be looking for... but ill try to figure it out anyway

sr_ls_boy commented on 26 September 2017 at 10:59 pm UTC

John Brooks might be able to help. He might recognize this.

Any way, anyone out there good with GDB?

  Go to:

Due to spam you need to Register and Login to comment.

Or login with...

Livestreams & Videos
Community Livestreams
See more!
Popular this week
View by Category
Latest Comments
Latest Forum Posts