Tux Racer (Linux), doesn't start

Support
#1

I’m on Linux Mint 20.3

When trying to run the Linux version it instantly crashes, the log outputs this:
Started initial process 10114 from gamemoderun /home/kamrat/Games/tux-racer/tuxracer
Start monitoring process.
ERROR: ld.so: object ‘/usr/$LIB/libgamemodeauto.so.0’ from LD_PRELOAD cannot be preloaded (cannot open shared object file): ignored.
./tuxracer-bin: error while loading shared libraries: libSM.so.6: wrong ELF class: ELFCLASS64
Monitored process exited.
Initial process has exited (return code: 32512)
All processes have quit
Exit with return code 32512

1 Like
#2

It’s not finding your 32 bit libSM (x11 session management library). Your distro may split that out as a separate “libsm” package (or may not provide it)

Try this:

sudo apt install libsm:i386

1 Like
#3

Hi, thank you for responding, when running that command I got this output in the terminal: Unable to locate package libsm:i386

However it got me looking in synaptic and there seemed to be a collection of 32-bit libraries there called “ia32.libs” which contained libsm, I downloaded this and now the log outputs something else when I try to run tux racer:

Started initial process 195516 from gamemoderun /home/kamrat/Games/tux-racer/tuxracer
Start monitoring process.
ERROR: ld.so: object '/usr/$LIB/libgamemodeauto.so.0' from LD_PRELOAD cannot be preloaded (cannot open shared object file): ignored.
./tuxracer-bin: error while loading shared libraries: libesd.so.0: cannot open shared object file: No such file or directory
Monitored process exited.
Initial process has exited (return code: 32512)
All processes have quit
Exit with return code 32512

so it seemed to have moved the problem instead, I did look in synaptic again and I found no package called libesd, I did find a packed called, libesd-java, while I didn’t think it would work I installed that one as well but there seems to be no change as expected.

In the description of libesd-java it says “Implementation of EsounD in pure Java”, searching for EsounD in synaptic nets me several results but nothing that looks like it will help me this time.

image
image846×240 33 KB

Looks like gnome maintains an ESD archive but I don’t know if it’s a good idea to just build these, especially since I’m too much of a noob to know if it would help me

#4

Well, is there any particular reason you’re fixated on that old tux racer binary? There’s a better fork of that called Extreme Tux Racer (“ETR”) that is easily compiled for x86-64.

Your distro even has packages for that :slight_smile:

sudo apt install extremetuxracer

You won’t need Lutris or anything to run that.

#5

Extreme tux racer is not the same game, it doesn’t have the same levels, characters or physics.

The levels are more detailed and look nicer in the old one as well while extreme tux racer is pretty barebones in comparison.

Before the suggestion comes: I’m aware that I can run it trough wine but since there’s a lutris-installer for tux racer (linux) I should be able to run it, I’d rather run things natevly too, even though it can cause more issues.

#6

I don’t think your distribution provides what you need to run that old game. This has nothing to do with Lutris.

Try compiling a 32 bit esound and try dropping the library in the game directory if you can’t find a compatible one from an older distro or something. (Don’t install the package, extract the library and put it in the game directory and use LD_LIBRARY_PATH if it doesn’t already)

P.S. That java implementation is not what you want.

1 Like
#7

I will try that thanks, but it’s getting late over here so I’ll do it tomorrow :slight_smile:

Thanks for being helpful :slight_smile:

#8

Hey there again, I compiled the latest source of ESD found on Index of /sources/esound/0.2/ and put it in the folder containing Tux Racer and pointed to the folder with the LD_LIBRARY_PATH like you said and it found it no issues, the only issue I ran in to is that it’s telling me it’s the wrong ELF-class again with that file (ELFCLASS64), I tried compiling older versions and it gave me the same thing unless the package was too old then it didn’t even let me configure it because of missing packages which I can’t find.

I think I’m giving up on this project for now, I’m planning moving over to Manjaro in the future and I saw that the AUR has libesd in it so I’ll try again then, this sucks a bit but what can you do, running old software without issues is pretty hard it seems.

However, I like learning new things so it’s not all for nothing, I want to thank you again Grogan for being helpful :slight_smile:

#9

That’s why I said to do a 32 bit build of it. Essentially, with a multi-lib gcc, set variables:

CC=“gcc -m32”
CXX=“g++ -m32”

You would also need any 32 bit dependencies the software you are compiling needs.

I also suggested to just grab one from an older distro (e.g. older ubuntu that still provided it for i386)

.deb files are just “ar” archives with .tar archives (and control files) inside. If you compiled anything, you have binutils installed and therefore ar

ar x filename.deb

Produces data.tar( or .tar.gz, or .xz) and a control.tar. You are interested in data.tar… extract it like normal and get the library (copy the real file, not the symlink and rename it appropriately… libesd.so.0 and stick it in the game directory)

I am actually trying to find one for you, but I’m coming up short. I’m thinking “Xenial” (ubuntu 16.0.4) but I’m getting dead ends on their packages.ubuntu.com site for xenial (it’s like Ubuntu has removed package archives)

1 Like
#10

I thought of taking one from 32 bit Slackware 14.2 and started investigating that, but then I realized that this just isn’t practical. Even if you were to take one from an older Ubuntu, it would have dependencies with broken .sonames.

For example, libesd will be linked against alsa libraries. The .soname would jibe (it’s still .so.2) but your distro would have to have a 32 bit libasound.so.2. Probably does.

Old libesd will also likely be linked against libaudiofile and things, which will be missing (unless your distro has a 32 bit libaudiofile.so.1). We could satisfy that too, but then actual audio libraries that the libaudiofile is linked against will be wrong sonames (e.g. libFLAC.so.8)

So you’re going to need a stack of old 32 bit libraries. This one won’t just be a “drop-in” from an older distro.

So yeah, that leaves compiling a 32 bit esound. Its only real dependency is libaudiofile, but you need a 32 bit one. You’d probably have to compile that too.

This stuff would indeed be easier on Arch/Manjaro (though the AUR does not provide lib32 builds of these things, we could certainly whip up some PKGBUILDs)

P.S. And don’t just “make install” 32 bit things. It would be OK if you did that to /usr/local wtih, say, that 64 bit build of esound but generally what you want to do is use a DESTDIR variable for the install. For example:

DESTDIR=/my/dir ninja install

or

make install DESTDIR=/my/dir

and take the 32 bit libraries from there.

1 Like
#11

I didn’t understand how to make a 32-bit build of the libraries and I didn’t know how to use the variables so I tried searching the internet for answers on how to do this but it was pretty confusing for me, I tried modifying the configure file and even the makefiles but with no luck.

I ended up running Ubuntu 12.04.5 (Precise Pangolin) from here in a virtual machine and installing esdlib in there after reading how to download packages for old ubuntu-distros, after that I tranferred the files (libesd and libaudiofile) to my host OS which worked fine and the game found and used them no problem once they where in my game folder so that worked, I did however run into another issue when running the game this time:

Started initial process 400621 from gamemoderun /home/kamrat/Games/tux-racer/tuxracer
Start monitoring process.
ERROR: ld.so: object ‘/usr/$LIB/libgamemodeauto.so.0’ from LD_PRELOAD cannot be preloaded (cannot open shared object file): ignored.
Tux Racer 1.1.1
A Sunspire Studios Production (http://www.sunspirestudios.com)
(c) 1999, 2000 Jasmin F. Patry
(c) 2001, 2002 Sunspire Studios, Inc.

Use of this software is subject to the terms set out in the file
EULA.txt, to which you must have agreed when installing this
software.
libGL error: MESA-LOADER: failed to open radeonsi: /usr/lib/dri/radeonsi_dri.so: cannot open shared object file: No such file or directory (search paths /usr/lib/i386-linux-gnu/dri:$${ORIGIN}/dri:/usr/lib/dri, suffix _dri)
libGL error: failed to load driver: radeonsi
libGL error: MESA-LOADER: failed to open radeonsi: /usr/lib/dri/radeonsi_dri.so: cannot open shared object file: No such file or directory (search paths /usr/lib/i386-linux-gnu/dri:$${ORIGIN}/dri:/usr/lib/dri, suffix _dri)
libGL error: failed to load driver: radeonsi
libGL error: MESA-LOADER: failed to open swrast: /usr/lib/dri/swrast_dri.so: cannot open shared object file: No such file or directory (search paths /usr/lib/i386-linux-gnu/dri:$${ORIGIN}/dri:/usr/lib/dri, suffix _dri)
libGL error: failed to load driver: swrast
X Error of failed request: BadValue (integer parameter out of range for operation)
Major opcode of failed request: 152 (GLX)
Minor opcode of failed request: 3 (X_GLXCreateContext)
Value in failed request: 0x0
Serial number of failed request: 42
Current serial number in output stream: 43
Monitored process exited.
Initial process has exited (return code: 256)
All processes have quit
Exit with return code 256

I did try to just drop the driver files in the tux racer-folder but that didn’t seem to work, I didn’t imagine it would, and even if it did I doubt the old drivers would have worked on my modern card.

This game seems to not like being played on modern linux-systems at all, I did however manage to run the game in the virtual machine and it’s pretty fun, I would rather not have to use a virtual machine for this but it’s an ok solution for now.

It just seems weird to me that there’s a lutris installer for a game that doesn’t run on modern linuxes without this much fiddling, I wonder what kind of system the author made the lutris installer in.

I want to thank you again Grogan for trying and sorry for getting a bit confused about your instructions, I am pretty new to fiddling with these things, I’ve been using linux for two years but I haven’t really done advanced stuff that much as of yet, but we all have to start somewhere.

I really do like linux and would like to learn a lot of these things though so it’s been fun trying to figure out how to do things :slight_smile:

#12

You don’t have 32 bit Mesa :slight_smile:

It’s failing to load your driver, trying to fall back to software rendering, and failing to find that too.

No, you won’t be able to drop the driver files in the game dir, you’ll have to install the i386 mesa packages.

I don’t know how they name them or how they split them up anymore, but this should be do-able. I’ll see if I can find out the commands you’ll need to install it.

For future reference though, you could have used those variables like (for example):

export CC="gcc -m32"
export CXX="g++ -m32"
./configure --prefix=/usr/local
make
make install DESTDIR=/my/dir

This would assume linker paths set up correctly to find 32 bit stuff in /usr/lib/i386-linux-gnu (or whatever their triplet is these days).

Most builds will take CC and CXX variables from the environment like that, or prepended on the command line

#13

That’s the thing though, I think I do, looking in synaptic it tells me I have all the i386 mesa packages installed when I do a search for mesa 386

image
image881×146 31.8 KB

unless it’s searching for something specific these should’ve done the trick no?

Thanks, I’ll try to remember how to do it properly in the future. :slight_smile:

#14

I don’t see hardware (amdgpu) specific drivers there. That helps though, now I know you’re using the kisak PPA and I see their nomenclature.

List of packages from kisak 22.3.5-kisak1-f
https://launchpad.net/~kisak/+archive/ubuntu/kisak-mesa/+build/25570521

libd3dadapter9-mesa-dbgsym_22.3.5~kisak1~f_i386.ddeb (31.1 MiB)
libd3dadapter9-mesa-dev_22.3.5~kisak1~f_i386.deb (57.0 KiB)
libd3dadapter9-mesa_22.3.5~kisak1~f_i386.deb (5.8 MiB)
libegl-mesa0-dbgsym_22.3.5~kisak1~f_i386.ddeb (403.7 KiB)
libegl-mesa0_22.3.5~kisak1~f_i386.deb (161.1 KiB)
libegl1-mesa-dev_22.3.5~kisak1~f_i386.deb (57.1 KiB)
libegl1-mesa_22.3.5~kisak1~f_i386.deb (53.1 KiB)
libgbm-dev_22.3.5~kisak1~f_i386.deb (56.9 KiB)
libgbm1-dbgsym_22.3.5~kisak1~f_i386.ddeb (107.1 KiB)
libgbm1_22.3.5~kisak1~f_i386.deb (77.6 KiB)
libgl1-mesa-dev_22.3.5~kisak1~f_i386.deb (53.1 KiB)
libgl1-mesa-dri-dbgsym_22.3.5~kisak1~f_i386.ddeb (38.9 MiB)
libgl1-mesa-dri_22.3.5~kisak1~f_i386.deb (7.2 MiB)
libgl1-mesa-glx_22.3.5~kisak1~f_i386.deb (53.1 KiB)
libglapi-mesa-dbgsym_22.3.5~kisak1~f_i386.ddeb (26.1 KiB)
libglapi-mesa_22.3.5~kisak1~f_i386.deb (73.9 KiB)
libgles2-mesa-dev_22.3.5~kisak1~f_i386.deb (53.1 KiB)
libgles2-mesa_22.3.5~kisak1~f_i386.deb (53.1 KiB)
libglx-mesa0-dbgsym_22.3.5~kisak1~f_i386.ddeb (535.2 KiB)
libglx-mesa0_22.3.5~kisak1~f_i386.deb (192.5 KiB)
libosmesa6-dbgsym_22.3.5~kisak1~f_i386.ddeb (14.1 MiB)
libosmesa6-dev_22.3.5~kisak1~f_i386.deb (56.4 KiB)
libosmesa6_22.3.5~kisak1~f_i386.deb (3.0 MiB)
libwayland-egl1-mesa_22.3.5~kisak1~f_i386.deb (53.1 KiB)
libxatracker-dev_22.3.5~kisak1~f_i386.deb (56.5 KiB)
libxatracker2-dbgsym_22.3.5~kisak1~f_i386.ddeb (10.8 MiB)
libxatracker2_22.3.5~kisak1~f_i386.deb (2.0 MiB)
mesa-common-dev_22.3.5~kisak1~f_i386.deb (1.9 MiB)
mesa-opencl-icd-dbgsym_22.3.5~kisak1~f_i386.ddeb (65.3 MiB)
mesa-opencl-icd_22.3.5~kisak1~f_i386.deb (10.6 MiB)
mesa-va-drivers-dbgsym_22.3.5~kisak1~f_i386.ddeb (20.2 MiB)
mesa-va-drivers_22.3.5~kisak1~f_i386.deb (3.2 MiB)
mesa-vdpau-drivers-dbgsym_22.3.5~kisak1~f_i386.ddeb (20.5 MiB)
mesa-vdpau-drivers_22.3.5~kisak1~f_i386.deb (3.3 MiB)
mesa-vulkan-drivers-dbgsym_22.3.5~kisak1~f_i386.ddeb (45.5 MiB)
mesa-vulkan-drivers_22.3.5~kisak1~f_i386.deb (8.6 MiB)

If you were missing, say libgl1-mesa-dri you’d do

apt install libgl1-mesa-dri:i386

P.S. In this package list, you don’t necessarily need (but may, even should, want) the dev packages for compiling against. You don’t need anything with “dbgsym” in the name (debug symbols) though, that’ll just be cruft for you.