Oolite won't start: libgnustep-base.so.1.28: cannot open shared object file

[Commander_X]

[...]
6) Start script:

#!/usr/bin/bash
LD_LIBRARY_PATH=./lib ./oolite
./oolite

This script shouldn't have line no. 3, i.e. you're trying to start oolite twice, once with the LD_LIBRARY_PATH variable set, and once without. The second (without the variable) will fail.

[...]
RESULT:

./oolite: symbol lookup error: /lib/libgnustep-base.so.1.29: undefined symbol: gnutls_x509_crt_get_issuer_dn3, version GNUTLS_3_4
[...]

For this error I have 2 explanations:
- see Hiran's comment about 1.29 not working in his attempts
- you should also try to make sure you insert a

Code: Select all

source /usr/share/GNUstep/Makefiles/GNUstep.sh

in the startup script prior to your LD_LIBRARY_PATH[...] command

./oolite: error while loading shared libraries: libpng14.so.14: cannot open shared object file: No such file or directory

[...]
lrwxrwxrwx 1 hmb hmb 21 Dec 26 20:21 libpng.so -> ../lib/libpng14.so.14
[...]

The above link will only work when you try to run this from the "lib" folder itself.
If (e.g.) you're trying to run this from oolite.app ("lib" folder's parent), then, unless you have a "lib" folder with these files at the same level with oolite.app (i.e. such that "./oolite.app/../lib" folder exists) the symlinks will fail.
A quick solution would be to replace all the links with pointers to the current folder, e.g.:

Code: Select all

libpng.so -> ./libpng14.so.14

A good way to check what/if you're missing, is to try to run:

Code: Select all

LD_LIBRARY_PATH=./lib ldd ./oolite

This will tell you what libraries are not "visible" for your executable.

[Cas Tell]

S u c c e s s !

Here's the recipe, the strangest problem has been solved in step 3. And here we are (md coded, can be easily transformed into PDF):

Code: Select all

\hyphenpenalty=10000

# A Recipe To Self-Compile Oolite's Latest Version

2023-12-27, version 1.0

In the following, we must distinguish text from commands. To make this easier, all commands you have to enter on the commandline start with $. Normal text which helps to understand better why we are doing things, looks like normal text :)

Follow every single step to build Oolite from source. If errors occur use the Oolite Linux forum and post the details, please!

## 1) Create a git clone

We need a directory to work in, let's create one, you may choose whatever name you wish, but the following recipe sticks to this one here:
```
$ mkdir ~/Oolite-Clone/
$ git clone https://github.com/OoliteProject/oolite.git
```
## 1) Install some libraries and applications
```
$ apt -y install git gobjc gnustep-devel make libsdl1.2-dev libvorbis-dev \
libopenal-dev g++ libespeak-dev libnspr4-dev
```
## 2) Some preparation
```
$ cd ~/Oolite-Clone/oolite
$ cp .absolute_gitmodules .gitmodules
$ git submodule update --init
$ git checkout -- .gitmodules
$ source /usr/share/GNUstep/Makefiles/GNUstep.sh
$ cd ~/Oolite-Clone/oolite/deps/Linux-deps/x86_64/lib_linker
$ ./make_so_links.sh
$ mkdir ~/Oolite-Clone/oolite/oolite.app/lib
```
Copy all the new symlinks which were created by the last command in the directory
```
~/Oolite-Clone/oolite/deps/Linux-deps/x86_64/lib_linker
```
as well as the libs in
```
~/Oolite-Clone/oolite/deps/Linux-deps/x86_64/lib
```
to
```
~/Oolite-Clone/oolite/oolite.app/lib
```
The links must reside together with the libs in the same directory, otherwise they're broken.

## 3) Create an important symlink

In the directory
```
/usr/lib/x86_64-linux-gnu
```
this link MUST exist:
```
libpng14.so.14 -> /home/hmb/Oolite-Clone/oolite/oolite.app/lib/libpng14.so.14
```
Due to hitherto unknown reasons oolite wants to find the libpng.so in there. libpng will only be found when this link exists.

## 4) Make
```
make -f Makefile release use_deps=yes -j$(nproc) # Done!
```
## 5) Create a start script
```
#!/usr/bin/bash
cd ~/Oolite-Clone/oolite/oolite.app
LD_LIBRARY_PATH=./lib
# Next line only for debugging.
# Uncomment if problems occur:
# ldd ./oolite
./oolite
```
# P L A Y !

Save this code in a file with the extension md and read it with
pandoc Oolite-Recipe.md | lynx -stdin
or convert it into a PDF file.

[hiran]

S u c c e s s !

Here's the recipe, the strangest problem has been solved in step 3. And here we are (md coded, can be easily transformed into PDF):

Code: Select all

\hyphenpenalty=10000

# A Recipe To Self-Compile Oolite's Latest Version

2023-12-27, version 1.0

In the following, we must distinguish text from commands. To make this easier, all commands you have to enter on the commandline start with $. Normal text which helps to understand better why we are doing things, looks like normal text :)

Follow every single step to build Oolite from source. If errors occur use the Oolite Linux forum and post the details, please!

## 1) Create a git clone

We need a directory to work in, let's create one, you may choose whatever name you wish, but the following recipe sticks to this one here:
```
$ mkdir ~/Oolite-Clone/
$ git clone https://github.com/OoliteProject/oolite.git
```
## 1) Install some libraries and applications
```
$ apt -y install git gobjc gnustep-devel make libsdl1.2-dev libvorbis-dev \
libopenal-dev g++ libespeak-dev libnspr4-dev
```
## 2) Some preparation
```
$ cd ~/Oolite-Clone/oolite
$ cp .absolute_gitmodules .gitmodules
$ git submodule update --init
$ git checkout -- .gitmodules
$ source /usr/share/GNUstep/Makefiles/GNUstep.sh
$ cd ~/Oolite-Clone/oolite/deps/Linux-deps/x86_64/lib_linker
$ ./make_so_links.sh
$ mkdir ~/Oolite-Clone/oolite/oolite.app/lib
```
Copy all the new symlinks which were created by the last command in the directory
```
~/Oolite-Clone/oolite/deps/Linux-deps/x86_64/lib_linker
```
as well as the libs in
```
~/Oolite-Clone/oolite/deps/Linux-deps/x86_64/lib
```
to
```
~/Oolite-Clone/oolite/oolite.app/lib
```
The links must reside together with the libs in the same directory, otherwise they're broken.

## 3) Create an important symlink

In the directory
```
/usr/lib/x86_64-linux-gnu
```
this link MUST exist:
```
libpng14.so.14 -> /home/hmb/Oolite-Clone/oolite/oolite.app/lib/libpng14.so.14
```
Due to hitherto unknown reasons oolite wants to find the libpng.so in there. libpng will only be found when this link exists.

## 4) Make
```
make -f Makefile release use_deps=yes -j$(nproc) # Done!
```
## 5) Create a start script
```
#!/usr/bin/bash
cd ~/Oolite-Clone/oolite/oolite.app
LD_LIBRARY_PATH=./lib
# Next line only for debugging.
# Uncomment if problems occur:
# ldd ./oolite
./oolite
```
# P L A Y !

Save this code in a file with the extension md and read it with
pandoc Oolite-Recipe.md | lynx -stdin
or convert it into a PDF file.

Thank you for sharing this. Maybe it's worth to look at how we build Oolite on Github and improve that.

But then you still recompiled from scratch. Did you not have access to the already existing artifacts? I still wanted to verify if the linux builds with use_deps=yes are good to use...

[Cas Tell]

Thank you for sharing this. Maybe it's worth to look at how we build Oolite on Github and improve that.

But then you still recompiled from scratch. Did you not have access to the already existing artifacts? I still wanted to verify if the linux builds with use_deps=yes are good to use...

Well, let's put it this way: I have changed and enhanced the recipe which is given in the README.md of Oolite to a degree that it works under Kali Linux. And yes, I used the make command with this use_deps option, and this definetely works fine!

Regarding the artifacts, I had no reason to deal with them. The recipe I've given here works 100%, no special steps are required (at least for me in my case on the given machine) to make this work.

I still do not know exactly what these artifacts are and when I would need them. Give me a use case with step-by-step explanation and I'll be glad to test it.

What I did not test was doing all this without a github account. But someone who wants to build Oolite this way, will have one or won't hesitate to create one. So...

I played a bit into the game and saw that sound works correct with the BGS oxp, and I could instantaneously download the current list of oxp's, no messing with config files required to make this work.

The last step which should be figured out would be some kind of installation script to get separate the dev files from the runtime environment. But that's not hard to do.

But let me know about this artifacts issue! Would really like to understand it better!

[hiran]

Regarding the artifacts, I had no reason to deal with them. The recipe I've given here works 100%, no special steps are required (at least for me in my case on the given machine) to make this work.

I still do not know exactly what these artifacts are and when I would need them. Give me a use case with step-by-step explanation and I'll be glad to test it.

Imagine you are a non-developer had do not intend to compile Oolite yourself. Thus you prefer to download precompiled binaries, which are available on the release page. Such a release is automatically built whenever there is a change on the master branch of the source code.

Since the addition of use_deps=yes is not on the master branch, you have to give some extra effort to access the automatically built files. these are called artifacts, and I tried to explain how you can access them here.

What I did not test was doing all this without a github account. But someone who wants to build Oolite this way, will have one or won't hesitate to create one. So...

All you needed Github for so far was to clone the repository and submodules. These repositories are publicly accessible so everything here can be done without Github account. Only for accessing the non-released build artifacts you need to authenticate.

The last step which should be figured out would be some kind of installation script to get separate the dev files from the runtime environment. But that's not hard to do.

It is being done in the automatic workflow, the results of which you skipped so far.
If you want to see how it is done, have a look at
https://github.com/OoliteProject/oolite ... l.yml#L108

The command executed there is one of

Code: Select all

make -f Makefile pkg-posix-nightly HOST_ARCH=$(uname -m)
make -f Makefile pkg-posix-test HOST_ARCH=$(uname -m)
make -f Makefile pkg-posix HOST_ARCH=$(uname -m)

As a result you will see an installer in this path:
https://github.com/OoliteProject/oolite ... l.yml#L125

[Cas Tell]

In the local directory oolite there is a subdir .github, in there is workflows, and there I see build_all.yml. This build_all.yml is identical with the one I get on github, when I enter Actions: There's a build_all link in the left hand frame. So I used it to get a build_all.yml which I downloaded and put it in this path. diff showed me that it was identical with the pre-existing one.

So, with the command make -f Makefile release use_deps=yes -j$(nproc) these artifacts should be included automatically, or don't they? Do I have to start the build_all.yml manually?

And my basic assumption that I get all artifacts by including the build_all.yml file, is it correct?

[Cas Tell]

Another question is:

Why is section 3) of my recipe crucial?

In other words, why is it necessary at all?

[Cas Tell]

On another computer I tried out my recipe. Everything worked quite fine until the start script produced this error:

Code: Select all

┌──(hmb㉿ZenBook14)-[~/Oolite-Clone/oolite]
└─$ ./start_oolite.sh
./oolite: symbol lookup error: /lib/libgnustep-base.so.1.29: undefined symbol: gnutls_x509_crt_get_issuer_dn3, version GNUTLS_3_4

Tried to fix it with different sorts of symlinks but to no avail.
Seems as if Oolite wants 1.20 but gets 1.29.
Suggestions?

[Mauiby de Fug]

A few observations that may or may not be accurate...

On Windows the gnustep library Oolite uses has been built with TLS support; is this the case with the Ubuntu version?

Looking at make_installer.sh the posix installers already seems to compile with deps=yes (via using the Makefile targets deps-release, deps-snapshot and deps-release-deployment targets), so hiran's addition to the Github Actions job matrix seems unnecessary.

Looking at the make_so_links.sh gnustep does not appear at all.

[hiran]

In the local directory oolite there is a subdir .github, in there is workflows, and there I see build_all.yml. This build_all.yml is identical with the one I get on github, when I enter Actions: There's a build_all link in the left hand frame. So I used it to get a build_all.yml which I downloaded and put it in this path. diff showed me that it was identical with the pre-existing one.

So, with the command make -f Makefile release use_deps=yes -j$(nproc) these artifacts should be included automatically, or don't they? Do I have to start the build_all.yml manually?

And my basic assumption that I get all artifacts by including the build_all.yml file, is it correct?

Sorry, you are still on the wrong path. You are downloading a file that is intended to be interpreted by Github's CI/CD pipeline. It will not execute on your local computer. However when Github executes that file the artifacts are generated. You just download them from Github.

Do not download the workflow file. Instead, choose one of the workflow runs, scroll down and pick one of the existing build artifacts. You receive a ZIP file with an Oolite installier inside.

[Cas Tell]

Okay, all misconceptions are out of the way now, so now we have two paths:

1) How to prepare the source files in a way that an average end-user with limited developer knowledge/experience can compile them?

In my humble opinion there are some hurdles to overcome, see my most recent attempt which again revealed problems with the gnustep library. Problems which cannnot be solved by simply using a few apt install commands are over the top, e.g. creating mysterious symlinks in mysterious places where you need a workday to find them. And if this is inevitable, we need concise cookbook recipes one can use step by step to end up with a successful compile run and a running game.

2) Checking the installers via early access to the artifacts

This is underway now, right? Not much to do on the user's side (e.g. me), just giving feedback.

Maybe we should split the thread at this point...

My latest self-compile from source recipe, coded as md (markdown):

Code: Select all

\hyphenpenalty=10000

# A Recipe To Self-Compile Oolite's Latest Version

2023-12-27, version 1.4

## Preface

This document evolved from my attempts to install Oolite on several computers running under Kali Linux. Kali is principally a Debian derivative, but it is not a classic distribution but a rolling one. I.e., there are no major version numbers as in Debian, Ubuntu etc. So it's quite easy to keep Kali up-to-date.

Due to these circumstances the hints and methods demonstrated in this document apply to Kali, and to a high degree also to Debian and Ubuntu. Other distros like Linux Mint haven't been tested but when they are based on Debian, you should try this out. In all other cases you may or may not profit from the information herein.

## How to use the document

In the following, we must distinguish text from commands. To make this easier, all commands you have to enter on the commandline start with $. Normal text which helps to understand better why we are doing things, looks like normal text :)

Follow every single step to build Oolite from source. If errors occur use the Oolite Linux forum and post the details, please!

Let's get started!

## 1) Create a git clone

We need a directory to work in, let's create one, you may choose whatever name you wish, but the following recipe sticks to this one here:
```
$ mkdir ~/Oolite-Clone/
$ git clone https://github.com/OoliteProject/oolite.git
```
## 1) Install some libraries and applications
```
$ apt -y install git gobjc gnustep-devel make libsdl1.2-dev libvorbis-dev \
libopenal-dev g++ libespeak-dev libnspr4-dev
```
## 2) Some preparation
```
$ cd ~/Oolite-Clone/oolite
$ cp .absolute_gitmodules .gitmodules
$ git submodule update --init
$ git checkout -- .gitmodules
$ source /usr/share/GNUstep/Makefiles/GNUstep.sh
$ cd ~/Oolite-Clone/oolite/deps/Linux-deps/x86_64/lib_linker
$ ./make_so_links.sh
$ mkdir ~/Oolite-Clone/oolite/oolite.app
$ mkdir ~/Oolite-Clone/oolite/oolite.app/lib
```
Copy all the new symlinks which were created by the last command in the directory ~/Oolite-Clone/oolite/deps/Linux-deps/x86_64/lib_linker/ to ~/Oolite-Clone/oolite/oolite.app/lib/:
```
$ cp ~/Oolite-Clone/oolite/deps/Linux-deps/x86_64/lib_linker/* \
~/Oolite-Clone/oolite/oolite.app/lib
```
The same goes for the libs in ~/Oolite-Clone/oolite/deps/Linux-deps/x86_64/lib/:
```
$ cp ~/Oolite-Clone/oolite/deps/Linux-deps/x86_64/lib/* \
~/Oolite-Clone/oolite/oolite.app/lib
```
The links must reside together with the libs in the same directory, otherwise they're broken.

## 3) Create an important symlink

In the directory
```
/usr/lib/x86_64-linux-gnu
```
this link **MUST** exist:
```
libpng14.so.14 -> /home/hmb/Oolite-Clone/oolite/oolite.app/lib/libpng14.so.14
```
To achieve this you have to become root. As root (you can use the command "$ sudo su" if you wish) you launch this sequence:
```
$ cd /usr/lib/x86_64-linux-gnu
$ ln -s /home/<your_specific_username>/Oolite-Clone/oolite/oolite.app/lib/libpng14.so.14
```
Due to hitherto unknown reasons oolite wants to find the libpng.so in there. libpng will only be found when this link exists.

## 4) Make

Call make:
```
$ cd ~/Oolite-Clone/oolite
$ make -f Makefile release use_deps=yes -j$(nproc)
```
## 5) Create a start script
```
#!/usr/bin/bash
cd ~/Oolite-Clone/oolite/oolite.app
LD_LIBRARY_PATH=./lib
# Next line only for debugging.
# Uncomment if problems occur:
# ldd ./oolite
./oolite
```
# P L A Y !

This recipe is still not perfect and may leave you with compile errors on your specific computer, but at least it contains some procedures to avoid this as far as possible at the time of this writing.

[hiran]

Do you have a Wiki account? Your build instructions could well go into the developer's corner.

[Cholmondely]

Most impressive, you two! Well done!

I just wish somebody could manage something similar for the dreaded AppleMac!

[Cas Tell]

No, I don't

[Cholmondely]

No, I don't

If you would like one, I can happily oblige.

By the way, did you know that somebody invented a slide rule for chemical formulae? (https://www.oughtred.org/
https://www.oughtred.org/jos/articles/V21.2_p08-15.pdf)