Legend of Grimrock

Legend of Grimrock

View Stats:
8Kuula Feb 14, 2015 @ 3:53am
[Linux] Not starting
I have tried reinstalling and deleting whole ~/.local/share/Almost Human directory, but for some reason LoG just do not start.

$ steam -applaunch 207170 Running Steam on ubuntu 14.04 64-bit STEAM_RUNTIME is enabled automatically
That was useless.

How I can start it so that I can see command line output? if there is any.
Or how to fix this?

OS: Ubuntu 14.04 64bit
nvidia GTX 980 (346.35)
Last edited by 8Kuula; Feb 14, 2015 @ 4:07am
< >
Showing 46-60 of 74 comments
Dr.Disaster Jul 1, 2015 @ 3:19pm 
Originally posted by alx242:
Even if they hired someone external resources to create the linux version we are plenty of people that have supported their product and that should be enough to make some movement on their behalf.

That's exactly, what AH did: they hired an external guy to do the port. Now the bad part is that this external dude either can't or won't support his work anymore :log_skull:

Originally posted by alx242:
Please Almost Human, hire some linux person to get on top of this. Perhaps you could even squeeze out Grimrock 2 for Linux as well :) I seriously want to finish this game on my Linux box :)

They first need the source code of this external dude that can't/won't help anymore before they could hire another guy to patch anything. Otherwise they need to hire a new guy to do the whole port again :triangle:
Last edited by Dr.Disaster; Jul 1, 2015 @ 3:20pm
fableman Jul 4, 2015 @ 12:50am 
Seriously, how hard can it be to debug the game and solve the segmentation fault issue? It always comes down to a few coffees, a few hours of debugging, reading a few forums/whitepapers and the problem is solved and after that you can safely resubmit the game to steam. I reckon they are just done with linux port due to lack of motivation to do any extra work on it. And please, don't BS me with this "they don't have the source code from the porter" crap. They always do (gamedev myself).
[LINUX]Wolfyrion Jul 4, 2015 @ 10:53am 
seriously no fix ? :o?
Dr.Disaster Jul 4, 2015 @ 2:49pm 
Originally posted by fableman:
Seriously, how hard can it be to debug the game and solve the segmentation fault issue? It always comes down to a few coffees, a few hours of debugging, reading a few forums/whitepapers and the problem is solved and after that you can safely resubmit the game to steam. I reckon they are just done with linux port due to lack of motivation to do any extra work on it. And please, don't BS me with this "they don't have the source code from the porter" crap. They always do (gamedev myself).

Well .. feel free to apply for the job then mr. gamedev!
Last time i checked back with AH they were still looking for a linux guy capable of doing it.
Last edited by Dr.Disaster; Jul 4, 2015 @ 2:51pm
fableman Jul 5, 2015 @ 2:09am 
Originally posted by Dr.Disaster:
Originally posted by fableman:
Seriously, how hard can it be to debug the game and solve the segmentation fault issue? It always comes down to a few coffees, a few hours of debugging, reading a few forums/whitepapers and the problem is solved and after that you can safely resubmit the game to steam. I reckon they are just done with linux port due to lack of motivation to do any extra work on it. And please, don't BS me with this "they don't have the source code from the porter" crap. They always do (gamedev myself).

Well .. feel free to apply for the job then mr. gamedev!
Last time i checked back with AH they were still looking for a linux guy capable of doing it.

Thanks, but I'm already in a pretty decent spot at this moment. Tbh, I'm merely here to express my feelings about the whole situation, nothing else.
BigDaddyDelta Jul 5, 2015 @ 6:24am 
Originally posted by directhex:
Originally posted by BigDaddyDelta:
I've created this small workaround for this game, So far it has only been tested on my system with a GTX 960 and drivers 349.16. Link: https://drive.google.com/open?id=0Bw5Xv02Yq2HrUlNSV01rRHpaNzQ&authuser=0

If you test it please let me know if it works or not.

Screenshot: http://s1.postimg.org/8sixagd8t/grimrock.jpg


UPDATE: Workaround still works for me with the new drivers 352.21

So your workaround is just to bundle a chunk of the NVIDIA driver with the game, such that it gets preferentially used?


Unfortunately yes, I'm not a programmer and I understand this workaround may break at any time as newer Nvidia drivers come out.

At least for the time being it lets me play the game without having to lock myself to older drivers, Doesn't leave out the fact that I'm still hoping for a proper fix from the devs.

Like I said, I can only test this on a GTX 960, if any 970+ owners can test this too I can forward more information to the dev.
Faugn Jul 5, 2015 @ 1:05pm 
OK, so this workaround (using the old drivers) does not work for me (I'm on Arch Linux, NVIDIA driver: version 352.21). I took a closer look at the issue: it seems to be a buffer overflow when handling the GL extensions string (more than 8K)... That's some sloppy code... Anyway, I've made a small library override, that "fix" the extensions string when glGetString(GL_EXTENSIONS) is called (by stripping the end to limit to 8K max). Not pretty, but it works: the game starts, and so far, I'm not seeing any graphical issue (all graphics set to max).

Here is a script to patch the Steam version:

#!/bin/sh set -x mv Grimrock.bin.x86 executable.x86 && printf '#!/bin/sh\nexec env LD_PRELOAD=./lib/glfix.so ./executable.x86 "$@"\n' >Grimrock.bin.x86 && chmod +x Grimrock.bin.x86 && gcc -m32 -D_GNU_SOURCE -shared -fPIC -lGL -ldl -x c - -o ./lib/glfix.so <<\EOF #include <stdio.h> #include <string.h> #include <dlfcn.h> #include <stdlib.h> #include <assert.h> #include <GL/gl.h> const GLubyte *(* __real_glGetString)(GLenum name); static GLubyte _gl_extensions[8 * 1024]; static __attribute__((constructor)) void _init(void) { __real_glGetString = dlsym(RTLD_NEXT, "glGetString"); assert(NULL != __real_glGetString); } const GLubyte *glGetString(GLenum name) { const GLubyte *res; res = __real_glGetString(name); if (GL_EXTENSIONS == name && NULL != res) { size_t len = strlen(res); if (len >= sizeof (_gl_extensions)) { GLubyte *end; strncpy(_gl_extensions, res, sizeof (_gl_extensions)); _gl_extensions[sizeof (_gl_extensions) - 1] = '\0'; end = strrchr(_gl_extensions, ' '); assert(NULL != end); len = end - &_gl_extensions[0]; assert(len < sizeof (_gl_extensions)); *end = '\0'; fprintf(stderr, "glGetString(GL_EXTENSIONS): stripping \"%s\" [%u]\n", res + len, strlen(res + len)); res = _gl_extensions; fprintf(stderr, "glGetString(GL_EXTENSIONS): returning \"%s\" [%u]\n", res, strlen(res)); } } return res; } EOF

It needs to be run from the Legend of Grimrock installation directory (default: ~/.local/share/Steam/SteamApps/common/Legend of Grimrock).

And for the record, I agree with fableman, how hard can it be to fix this issue from AH side?
Last edited by Faugn; Jul 5, 2015 @ 1:10pm
Dr.Disaster Jul 5, 2015 @ 2:32pm 
As hard as it can be to find a reliable linux dev ..
Petri  [developer] Jul 8, 2015 @ 12:24am 
Apologies for the long delay!

We have just pushed a new Linux beta to Steam that should fix this issue. Could you please test it by opting into the "linux_beta" branch (in Library -> Legend of Grimrock -> Properties -> Betas)?

I hope this finally solves this embarrassingly long standing issue.
von Jul 8, 2015 @ 1:31am 
Originally posted by petrih:
Apologies for the long delay!

We have just pushed a new Linux beta to Steam that should fix this issue. Could you please test it by opting into the "linux_beta" branch (in Library -> Legend of Grimrock -> Properties -> Betas)?

I hope this finally solves this embarrassingly long standing issue.
Works for me, thank you.
intel core i5-3570, nvidia gtx970 (driver ver. 352.21), arch linux
Faugn Jul 8, 2015 @ 4:26am 
Originally posted by petrih:
Apologies for the long delay!

We have just pushed a new Linux beta to Steam that should fix this issue. Could you please test it by opting into the "linux_beta" branch (in Library -> Legend of Grimrock -> Properties -> Betas)?

I hope this finally solves this embarrassingly long standing issue.

Works fine here too (NVIDIA GTX960, driver 352.21, Arch Linux). Can you comment on what was the underlying issue? I'm curious.
Petri  [developer] Jul 8, 2015 @ 6:22am 
Originally posted by Faugn:
Works fine here too (NVIDIA GTX960, driver 352.21, Arch Linux). Can you comment on what was the underlying issue? I'm curious.
The issue was caused by a buffer overflow bug, like you described earlier. I guess the real issue is that we are a very tiny team (just 1 programmer) with practically no Linux experience and trying to juggle with multiple projects and platforms at the same time (win, mac, linux, ios). Again apologies for taking so long to fix this.
Faugn Jul 8, 2015 @ 6:37am 
Originally posted by petrih:
Originally posted by Faugn:
Works fine here too (NVIDIA GTX960, driver 352.21, Arch Linux). Can you comment on what was the underlying issue? I'm curious.
The issue was caused by a buffer overflow bug, like you described earlier. I guess the real issue is that we are a very tiny team (just 1 programmer) with practically no Linux experience and trying to juggle with multiple projects and platforms at the same time (win, mac, linux, ios). Again apologies for taking so long to fix this.

Better late than never! Thanks for taking the time to reply. A great Linux tool for finding such memory related issues is Valgrind (it's what I used in combination with strace and ltrace). Cheers.
Squiddy Jul 8, 2015 @ 7:18am 
Fantastic! Tested it working! Thank you so much for your effort and not leaving us in the cold, it's very much appreciated.
Nabushi Jul 8, 2015 @ 7:23am 
Thanks for this :tlove:
< >
Showing 46-60 of 74 comments
Per page: 1530 50

Date Posted: Feb 14, 2015 @ 3:53am
Posts: 74