Running Thrive on GNU/Linux when the provided libc version isn't the one needed

Current Game
1

I’m not sure if this topic was created in the correct category.
When running Thrive Launcher I get the following outputted/output to my screen:

Process Started
ERROR: /home/kurim/Software/Thrive Launcher-linux-x64/installed/LINUX_Thrive.0.3.4/Thrive-0.3.4/bin/Thrive: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.22' not found (required by ./libgnutls.so.30) /home/kurim/Software/Thrive Launcher-linux-x64/installed/LINUX_Thrive.0.3.4/Thrive-0.3.4/bin/Thrive: /usr/lib/x86_64-linux-gnu/libgomp.so.1: version `GOMP_4.0' not found (required by ./libsoxr.so.0)
ERROR: /home/kurim/Software/Thrive Launcher-linux-x64/installed/LINUX_Thrive.0.3.4/Thrive-0.3.4/bin/Thrive: /usr/lib/x86_64-linux-gnu/libgomp.so.1: version `GOMP_4.0' not found (required by ./libraw.so.15)
child process exited with code 1

That part with Gomp can probably be easily handled by compiling the needed software.
I have version 2.19 of libc instead of the needed 2.22. The version I’m currently using is already the latest provided by the repository of the distribution. As libc is a pretty important library, I don’t think that updating it is the best thing to do.
Maybe installing another version of libc alongside the existing one helps. But I’m not really sure how this should be done.

My question is: What should be done to get the software running?

1 Like
2

I can’t remember what the included libraries are right now but you could try compiling libc 2.22 without installing it. Then copy the created libc.something.so to thrive/bin/lib and thrive should attempt to use it instead of the system one. That might help.

1 Like
3

Thanks, I will try that.

4

I’ve tried it. There was no lib directory under bin but I saw that there were many libs in the bin directory itself so I copied the library into that directory. Now, I no longer get an error about libc. I will now try to get a more recent version of gomp.
Thanks, @hhyyrylainen.

5

Let me know if you get it working. I’m probably thinking about the next version that will have a separate lib folder on linux to reduce the clutter in the bin folder.

6

The libgomp1 version from the repository seems to be the same as ubuntu’s. I’ve read that Ubuntu should have little trouble with running Thrive. So installing a newer package probably won’t fix it, I think…?

This stackoverflow question seems to be related(I have versions 4.9 and 4.8 of gcc).

I am going to try compiling Thrive from source to see if I get it running somehow.

7

The next version should be easier on every distros to install. There is a video where I show how easy it is to compile it on a fresh Ubuntu virtual machine on the revolutionary games studio YouTube channel.

1 Like
8

I found your video.
When running SetupThrive.rb I get this error message:

SetupThrive.rb:24:in `require_relative': /home/kurim/Software/Thrive/RubySetupSystem/RubyCommon.rb:75: syntax error, unexpected tLABEL (SyntaxError)
def runOpen3(*cmdAndArgs, errorPrefix: "", redError: false)
                                      ^
	from SetupThrive.rb:24:in `<main>'

(I payed attention to correctly line up the “^” with the line before it.)
It’s a syntax error. Maybe the Ruby interpreter I use is not the same as the one the file was written for?
Looks like that’s the case. Because the output of ruby -v is:

ruby 1.9.3p484 (2013-11-22 revision 43786) [x86_64-linux]

The major version of the sample output of that command on the Leviathan Game Engine prequisites is 2 while mine is 1. I’ll see if I get a later version.

9

I have installed a newer version of Ruby(2.5.1) and now I get a different error:

Starting RubySetupSystem run.

ERROR:  unknown packages for os: trisquel
Stack trace for error: 
/home/kurim/Software/Thrive/RubySetupSystem/Libraries/SetupLeviathan.rb:31:in `depsList'
/home/kurim/Software/Thrive/RubySetupSystem/Installer.rb:36:in `doPrerequisiteInstalls'
/home/kurim/Software/Thrive/RubySetupSystem/Installer.rb:108:in `block in run'
/home/kurim/Software/Thrive/RubySetupSystem/Installer.rb:104:in `each'
/home/kurim/Software/Thrive/RubySetupSystem/Installer.rb:104:in `run'
SetupThrive.rb:84:in `<main>'

I don’t know what could be done here besides trying to run it on a different distribution(trisquel is what I’m currently using). I’m not really sure what this error is trying to tell me.

10

It is telling you that It only has the right package names for Fedora and Ubuntu. You can run the setup with option --no-packagemanager to disable the automatic installation. You will then need to manually install all the needed packages for compiling all the parts.

1 Like
11

I’ve installed the dependencies that were listed in RubySetupSystem/Libraries/SetupLeviathan.rb and added the --no-packagemanager option. For some reason the output remains the same. I’ve tried to see what happens if I enter invalid options and the output was this:

Traceback (most recent call last):
    2: from SetupThrive.rb:61:in `<main>'
    1: from SetupThrive.rb:61:in `require_relative'
/home/kurim/Software/Thrive/RubySetupSystem/RubySetupSystem.rb:101:in `<top (required)>': invalid option: --yuefgeu (OptionParser::InvalidOption)

So neither was it considered an invalid option nor did it prevent the error message.

The packages listed in RubySetupSystem/Libraries/SetupLeviathan.rb have the same name as on my distro. So I have commented out that part that checks what the value of os is and made depsList always return [ "cscope", "libboost-dev", "libsdl2-dev", "imagemagick" ]:

  def depsList
    os = getLinuxOS

    #if os == "fedora" || os == "centos" || os == "rhel"
    #  return [
    #    "cscope", "boost-devel", "SDL2-devel", "ImageMagick"
    #  ]
    #end

    #if os == "ubuntu"
    #  return [
    #    "cscope", "libboost-dev", "libsdl2-dev", "imagemagick"
    #  ]
    #end
    return [ "cscope", "libboost-dev", "libsdl2-dev", "imagemagick" ]
    onError "#{@name} unknown packages for os: #{os}"
  end

I will now try to run it and see what happens.

12

Seems to be workig. Let’s see if any error occurs.

13

Are you using the “fix_everything” branch. As it’s only on that branch that I have fixed the disabling the automatic installing of deps. On the master branch the no-packagemanager option skips installing but will still check the os name and fail.

14

No, I’m using the master branch. That may explain it.

15

Yep.
If you made changes you want to make sure everything is clean after changing branches.

16

Ok, thanks.
If any error occurs I’ll try to use the fix_everything branch.