Linux version of The Guild of Thieves doesn't start for me any more

I just noticed that when I try to start The Guild of Thieves (Linux version) from the Itch client, it immediately quits. If I try it from a command prompt, I see this:

$ ./TheGuild-linux-
scanning for plugin in /tmp/.mount_QzTcKv/usr/bin
loading plugin /tmp/.mount_QzTcKv/usr/bin/
engine loaded,
data dir, /home/d91tan/.local/share/Brahman/guild
config dir, /tmp/.mount_QzTcKv/usr/bin/assets
loaded 2125 symbols
/tmp/.mount_QzTcKv/usr/bin/TheGuild: symbol lookup error: /usr/lib/x86_64-linux-gnu/ undefined symbol: FT_Done_MM_Var

Searching for the problem, and applying a suggestion from a completely unrelated AppImage, I came up with this workaround:

$ ./TheGuild-linux- --appimage-extract
$ cd squashfs-root
$ rm lib/
$ ./AppRun

I guess there must be some incompatibility with the bundled version of libfreetype. I noticed that neither The Pawn nor Jinxter seem to include it, and they both run just fine. I'm using the unstable version of Debian, if that makes any difference.


  • edited November 2019

    Hi Erik,
    yes, we are aware of the problem and a Guild update is in the works. This is a conflict between the bundled Qt version and the included libs with some libs on newer distros, resulting in problems with libharfbuzz and libfontconfig.
    Will send PM with update on the matter.

  • I didn't notice until today, but apparently the game was updated recently and now it seems to work fine again. Thanks!

  • Oh wait, I spoke too soon. We had a private discussion about a problem where the game usually hangs for me when leaving the mill, and that problem still seems to persist.

  • Strange. Do you perhaps still have access to the test build I sent? Actually the test build and the version on itch should be identical. Can you perhaps test again with setting the Qsg_render_loop variable to threaded?

  • @stefan said:
    Strange. Do you perhaps still have access to the test build I sent? Actually the test build and the version on itch should be identical. Can you perhaps test again with setting the Qsg_render_loop variable to threaded?

    I had actually removed them, but fortunately I could recover them from a backup. :)

    As it turns out, the TheGuild-linux- file in my Itch directory isn't quite identical to the one you sent me. The only differences are in the TheGuild.wrapper file:

    --- squashfs-root- 2020-02-10 18:21:12.172788658 +0100
    +++ squashfs-root- 2020-02-10 18:21:23.000681232 +0100

    if [ -z "$SKIP" ] ; then
    if [ $NUMBER_OF_ARGS -eq 0 ] ; then

    • exec env QSG_RENDER_LOOP=threaded "${BIN}"
    • exec "${BIN}"

    • exec env QSG_RENDER_LOOP=threaded "${BIN}" "${args[@]}"

    • exec "${BIN}" "${args[@]}"

    The one that sets QSG_RENDER_LOOP to "threaded" (i.e. the test build) works for me. The one that doesn't (i.e. the one on Itch) hangs.

  • Thanks a lot for trying. This is really strange. IIRC you have a graphics card with hardware acceleration, don't you? But it seems, for some reason Qt falls back to the basic render loop (pushing all rendering onto the cpu), although this shouldn't happen when hardware accelaration is available. Can you perhaps run glxinfo |grep render and check whether it uses llvmpipe?

  • @stefan said:
    Can you perhaps run glxinfo |grep render and check whether it uses llvmpipe?

    I assume you mean the OpenGL renderer string, and not all the extensions that just happen to include the word "render" in their names:

    "OpenGL renderer string: AMD BONAIRE (DRM 2.50.0, 5.4.0-3-amd64, LLVM 9.0.1)"

    (I haven't enabled the experimental Vulkan support, though. I've been tempted, but I don't think I have anything that would need it.)

  • Thanks, yes. This suggests that it doesn't use llvmpipe. So actually, it should use the threaded renderer. So either the Qt docs are wrong (they say that the renderer is always threaded except for llvmpipe rendering) or there is something going wrong in Qt with detecting your renderer.

  • Ok, the Qt docs are a little different now since I tread them the last time: "The non-threaded render loop is currently used by default on Windows with ANGLE or a non-default opengl32 implementation, macOS with OpenGL, and Linux with some drivers. For the latter this is mostly a precautionary measure, as not all combinations of OpenGL drivers and windowing systems have been tested. At the same time implementations like ANGLE or Mesa llvmpipe are not able to function properly with threaded rendering at all so not using threaded rendering is essential for these."

    So, perhaps, your machine is using a driver that Qt defaults to non-threaded rendering.
    Hmm, I guess, always forcing the threaded renderer might cause problems on other machines. Perhaps I can add a small option to the wrapper script which enables the threaded renderer.

  • I don't know if this is a clue or not, but as an experiment I turned off the Image Scaling ("Resize images to fit") setting and pulled down the picture to always be visible. (Though that doesn't seem to work quite as well has I had hoped, because if I enter a room without a picture, the picture is hidden and then I have to pull it down again later.)

    Then I tried walking back and forth between Inside the mill and Golden Wheatfield again. It doesn't hang, but sometimes when i leave the mill the picture for the Golden Wheatfield isn't shown. If I walk back into the mill again, the picture there isn't animated.

    I still get the feeling that there is some problem that's triggered by going from a room with an animated picture to one with a static picture, but I'm not familiar enough with the game to know if there are any other such cases I could easily test.

    If I leave Image Scaling on, the game still often hangs for me when leaving the mill.

  • Thanks for the observation. I will intensivly test this again as soon as Corona gives me a break. Guild is the only remaster so far which had original animations. Perhaps there IS something wrong with the animations. Would be much easier if I could trigger the problem somehow, but except for the high cpu usage because of the threading problem we discussed I couldn't get the program to hang. But I will have another go at it.

  • @stefan said:
    But I will have another go at it.

    Is there anything I can do to help debugging it? I can compile the code from the brahman Github repository (once I figured out that the build system doesn't like if the directory it's in has spaces in its name), but I don't know where to go from there, or even if that's the way to go.

  • Thanks a lot for the offer! Will send PM so we can try to sort this out. Since I am cross-compiling my compiling workflow ist somewhat different than it is described in the repo

Sign In or Register to comment.