How do I start the Linux version of X3: Reunion from GOG in Fedora?

Hoi, I recently bought the Linux version of X3: Reunion from GOG, but I can't find a way to start it.

My system: Fedora 32, 64-bit version

I went via terminal into the X3 Reunion folder and started it by:

./start.sh

Which gave me:

./X3R_config: error while loading shared libraries: libgtk-x11-2.0.so.0: cannot open shared object file: No such file or directory

I looked in the folder /usr/lib/ and libgtk-x11-2.0.so.0 was there.

Then I thought, oh, I forgot to install the mentioned programs listed on the GOG page.

Which were:

Requires the following packages to be installed: libc6:i386 libasound2:i386 libasound2-data:i386 libasound2-plugins:i386 libgtk2.0-0:i386 libxml2:i386 and dependencies. This game comes with a 32-bit binary only

Through internet research I think I found the corresponding Fedora programs and installed them:

glibc-devel.i686, which installed libxcrypt-devel.i686 as dependency
alsa-lib.i686 (was already installed)
alsa-lib-devel.i686
alsa-plugins-pulseaudio.i686 (because pulseaudio was the only one installed in the 64-bit version I thought that would be the one for this game)
gtk2.i686, which installed atk.i686, gdk-pixbuf2-modules.i686 and jasper-libs.i686 as dependencies
libxml2.i686
libxml2-devel.i686, which installed cmake-filesystem.i686, xz-devel.i686, xz-devel.x86_64 and zlib-devel.i686 as dependencies

Then I tried to start the game again, this time I got:

./X3R_config: lib/libz.so.1: version `ZLIB_1.2.9' not found (required by /lib/libpng16.so.16)

Through some research I came to this site here: https://stackoverflow.com/questions/48306849/lib-x86-64-linux-gnu-libz-so-1-version-zlib-1-2-9-not-found

and tried the second solution:

cd /your_software/../lib/ (the directory containing libz.so.1)
mv libz.so.1 libz.so.1.old
ln -s /lib/x86_64-linux-gnu/libz.so.1

Because in Fedora is no lib/x86_64-linux-gnu/ I found out that the corresponding folder should be lib64

So I did:

cd /usr/lib/
sudo mv libz.so.1 libz.so.1.old
sudo ln -s /lib64/libz.so.1

Sadly this didn't help.

Recently I had a similar case with the Linux version of Mount & Blade: Warband from GOG, which gave me after start something like this:

error while loading shared libraries: libcurl-gnutls.so.4: cannot open shared object file: No such file or directory

But the solution for Mount & Blade: Warband was:

sudo ln -s /usr/lib64/libcurl.so.4 /usr/lib64/libcurl-gnutls.so.4

And Mount & Blade: Warband started after that normally.

Maybe that helps or will give an additional idea how to get X3: Reunion to start...

If I forgot anything I will add it, I only use Linux for browsing and some office / gaming, so when it comes down to it, I am only a beginner ;)

Thank you in advance.

Small update

So, I put the libz.so.1, which I compiled from source like @aphid showed it, into the ~/GOG Games/X3 Reunion/game/lib/ folder, but renamed the previous libz.so.1 to libz.so.1.old.

then I got:

./start.sh 
Running X3: Reunion
Language detected: English
./X3R_config: symbol lookup error: /lib/libxcb-shm.so.0: undefined symbol: xcb_send_request_with_fds

which lead me to:

this

where someone had the same issue, but for X3 Terran War.

Well yeah, it's an other game, but the same series, so I thought the following might work:

Solution there was to delete the lib folder in the root folder of the game (that one next to docs, game, start.sh.,...) and keep in the lib folder located in games only with:

libavcodec.so.53
libavformat.so.53
libavutil.so.51
libbz2.so.1.0
libcrypto.so.1.0.0
libGLEW.so.1.13
libswscale.so.2

Of course I saved the ~/GOG Games/X3 Reunion/lib and ~/GOG Games/X3 Reunion/game/lib/ before doing this

which got me:

./start.sh 
Running X3: Reunion
Language detected: English
libGL error: No matching fbConfigs or visuals found
libGL error: failed to load driver: swrast
X Error of failed request:  GLXBadContext
  Major opcode of failed request:  153 (GLX)
  Minor opcode of failed request:  6 (X_GLXIsDirect)
  Serial number of failed request:  107
  Current serial number in output stream:  106

which lead me with a search for failed to load driver: swrast to this:

Answer#6

So maybe 32-bit-nvidia-libs might help, or would they conflict with the current 64-bit-libs? X3: Reunion is a 32-bit only game afterall.

Currently installed ones which are 64-bit packages:

akmod-nvidia-340xx
kmod-nvidia-340xx-5.11.11-100.fc32.x86_64
kmod-nvidia-340xx-5.11.12-100.fc32.x86_64
kmod-nvidia-340xx-5.11.14-100.fc32.x86_64
nvidia-texture-tools
xorg-x11-drv-nvidia-340xx
xorg-x11-drv-nvidia-340xx-kmodsrc
xorg-x11-drv-nvidia-340xx-libs
xorg-x11-drv-nvidia-libs

I would then just install the .i686 ones...

Or would this option be a dead end?

Update 2

Ok, installed now the 32-bit nvidia libraries and it starts now. Got help from here.

Also found out that it will start when you delete/rename the ~/GOG Games/X3 Reunion/lib folder. And you can keep all files in the ~/GOG Games/X3 Reunion/game/lib/ folder but we had to switch out the libz.so.1 with the previous compiled one.

I will write a detailed answer in the answer section to this now.

Best Answer

You should install zlib.i686 in addition to the regular zlib (x64), and (force) your game to link to it. It may work immediately, or you may have to use symlinks to get the game to load the correct library version.

The old version of zlib I need doesn't have an installer anymore, how do I install from source?

If the game is specifically looking for 1.2.9 (an obsolete version) then while we could try to utilize a newer version, this might cause bugs or crashes (although I guess that to be unlikely; this is a compression library which should want to be backwards-compatible). So there's no easy to install packages, which means you will have to compile the code yourself.

For that, you need a compiler. Take a look at the file Makefile.in. It contains all the instructions to compile the program. It also seems to be written in C, so we need a C compiler. I recommend installing either gcc or clang via your package manager if you don't have these already.

I recommend creating a working directory (in this example: ~/zlib129/). If you're paranoid, you can chroot into this directory to prevent any commands executed to compile code from affecting the rest of your system. Then commands to proceed would look like:

# Creates a directory to house the source code
mkdir ~/zlib129/
mkdir ~/zlib129/source/
# Create a directory to house the output of the compilation
mkdir ~/zlib129/chroot/
# Go into the directory
cd ~/zlib129/source/
# Download the zlib archive
wget https://zlib.net/fossils/zlib-1.2.9.tar.gz
# Extract it, skipping the root folder. 
tar -xvzf zlib-1.2.9.tar.gz --strip-components=1
# Let's check out how to compile it
nano makefile.in
### Read the instructions on how to compile...
./configure 
make install prefix=/home/grubbel/zlib129/chroot/
### Move the library to where we want it. 
### One easy thing to just do is put it in the game's lib folder (if it has one preconfigured). 
mv ~/zlib129/chroot/lib/libz.so.1 /path/to/game/lib/libz.so.1

Note: If you manage to compile the library, but the game can't find it in its own folder, then try using the LD_LIBRARY_PATH environment variable trick from my comment.

The reason why your solution doesn't work:

System libraries typically come in two flavors, in addition to a host of versions. Typically these two flavors (64- and the older 32-bit) are put in different folders. Usually something akin to /lib versus /lib64. For historic reasons distributions don't have the same naming convention for this.

By symlinking to it, you are trying to load a 64-bit library into a 32-bit binary. This won't work, because the pointer sizes are different. Pointers are a thing that all C and C++ programs must use to pass variables (such as buffers with data or text in them) between eachother.

A pointer is a number pointing to a location in memory; the N-th byte in virtual memory. 32-bit (or i686, from the name of the ubiquitous 32-bit Intel processor series 286..386..486, etc.), programs, as the name implies, use pointers that are 32 bits in width, or 4 bytes. 64-bit programs, on the other hand, use pointers that are 64 bits in width, or 8 bytes.

So when zlib expects a pointer to a string to be zipped (compressed), it expects a 64-bit address. It would segmentation fault (the OS terminates programs that try to access nonexistent or unpermissable memory) and crash if you gave it a 32-bit address instead , as the other 32 bits would be filled with random garbage. The same goes the other way around: the game wouldn't be able to interpret a 64-bit address returned from the library because it wouldn't fit in the variable.

It's likely that your linker won't even let you do this and will loudly complain to you instead of letting your application halt and catch fire.

Why do I sometimes have to symlink these libraries?

The game wasn't made with the consideration in mind that one day there could be multiple pointer sizes in use on the same system. It also was made on a linux system where libraries may have been in /lib instead of /usr/lib, and this may have been hardcoded. There are a lot more linux distributions nowadays and conventions have changed. Things usually work but you may need to fiddle to get older programs to behave properly.

When it was programmed, 64-bit PC's didn't exist yet. As far as it is concerned, a pointer is a 32-bit unsigned integer. In fact, a lot of game developers get even this wrong and freely cast to signed ints, which is why a some older games crash as soon as they get to 2GiB memory and why Windows has a special flag that the programmer needs to set before a 32-bit app is allowed more than 2GiB memory.