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

[Cas Tell]

Most impressive, you two! Well done!

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

Unfortunately, I don't have one . And I don't know anybody who uses one.

Nevertheless, would a hackmac be sufficient or do you need the real iron for testing? (I can't promise anything, that's just out of curiosity at the moment...)

[Cas Tell]

No, I don't

If you would like one, I can happily oblige.

Okay, fine, we can give this a try .

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)

No ! I've seen tons of slide rules in the past, and I once had one to calculate the load balance of a Douglas C-54 Skymaster, aka raisin bomber. But this chemical type I've never heard of, interesting!

[Cholmondely]

Nevertheless, would a hackmac be sufficient or do you need the real iron for testing? (I can't promise anything, that's just out of curiosity at the moment...)

I'm unsure. Phkb has one of those, and on it the Digebiti planet texture he created apparently looks top-notch. On my unhacked mac it looks pale and insipid and washed out! It could be the curse of the Witchspace Lobster who does seem to have it in for your humble servant...

Okay, fine, we can give this a try .

Righty-ho! A pm with the dreaded details is on its way to you!

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)

No ! I've seen tons of slide rules in the past, and I once had one to calculate the load balance of a Douglas C-54 Skymaster, aka raisin bomber. But this chemical type I've never heard of, interesting!

I rather think that we need another version for balancing national budgets. If our wonderful politicians don't do so, we can wallop them over the head with the slide rules. Particularly egregious cases could be impaled on them (cf Byzantine Empire).

[Cas Tell]

I still wonder why on the same computer (!) the installation of 1.90 works smoothly, but the newer versions fail. There must have been some crucial change regarding libgnustep which has broken the old installation environment. And it's also strange that nobody had this on his radar.
Is there anyone around who was involved in these changes and can tell something about it?

I have tested especially the first release after 1.90, 1.91.0.7570. This already fails with the notorious libgnustep error:

Code: Select all

./oolite.app/oolite: error while loading shared libraries: libgnustep-base.so.1.28: \
cannot open shared object file: No such file or directory

[another_commander]

I still wonder why on the same computer (!) the installation of 1.90 works smoothly, but the newer versions fail. There must have been some crucial change regarding libgnustep which has broken the old installation environment. And it's also strange that nobody had this on his radar.
Is there anyone around who was involved in these changes and can tell something about it?

We had it on the radar since day 1 that Linux deployment would be problematic for Oolite 1.91. The big change that happened post-1.90 is that we lost one of our main Linux maintainers, who had managed to set up a build environment capable of generating builds for Linux that were completely independent of any local system libraries. Those builds were self-contained and relied on gnustep-1.20.1 (which is what the Windows port uses as well). We do not have this setup with the automated github builds now. Linux binaries are currently made with whatever versions of gnustep are available to the github runners used to automate the build process.

I'm afraid I can't give a more in-depth explanation as Linux is not my field of expertise. However, the last known Linux build that is guaranteed to be able to run on all Linux distros is here: https://github.com/OoliteProject/nightlies/releases - it is basically 1.90 with a few bug fixes.

Additional information on this matter from our Linux ex-maintainer, with instructions on what to do to achieve a works-for-all environment here: https://bb.oolite.space/viewtopic.ph ... 06#p289006

[Cas Tell]

This thread, Building Oolite 4 Linux (https://bb.oolite.space/viewtopic.php?f=9&t=21369) was indeed helpful, it contains a script which was meant to run under a fresh Ubuntu:

Code: Select all

#!/bin/bash

# install all the necessary packages
sudo apt update
sudo apt -y install git gobjc gnustep-devel make libsdl1.2-dev libvorbis-dev libopenal-dev g++ libespeak-dev libnspr4-dev

# download source and dependencies
git clone https://github.com/OoliteProject/oolite.git
cd oolite
cp .absolute_gitmodules .gitmodules
git submodule update --init
git checkout -- .gitmodules

# this is necessary, as otherwise textures aren't loaded correctly
rm deps/Linux-deps/include/png.h
rm deps/Linux-deps/include/pngconf.h

# compiling
source /usr/share/GNUstep/Makefiles/GNUstep.sh
make -f Makefile release -j$(nproc)

To my surprise it worked superbly well on my Kali machine! After the script finished without any complaints, I had the Oolite directory and just needed to start oolite.app/oolite.
The version was 1.91 and should be the most recent one.
I need a break now, then I'll try to find out why this one worked and all other attempts did not.

Okay, break over: Used the above script on a Kali machine which has never seen Oolite before, and it worked like a charm. I'd wish I had an option in Oolite to show this monster version & release ID, but I assume it can only be the most recent release which gets installed. In the script there are no references to something else. On the page https://github.com/OoliteProject/oolite.git I do see the code published most lately, so the script should use this and nothing else. Right?

[hiran]

This thread, Building Oolite 4 Linux (https://bb.oolite.space/viewtopic.php?f=9&t=21369) was indeed helpful, it contains a script which was meant to run under a fresh Ubuntu:

Code: Select all

#!/bin/bash

# install all the necessary packages
sudo apt update
sudo apt -y install git gobjc gnustep-devel make libsdl1.2-dev libvorbis-dev libopenal-dev g++ libespeak-dev libnspr4-dev

# download source and dependencies
git clone https://github.com/OoliteProject/oolite.git
cd oolite
cp .absolute_gitmodules .gitmodules
git submodule update --init
git checkout -- .gitmodules

# this is necessary, as otherwise textures aren't loaded correctly
rm deps/Linux-deps/include/png.h
rm deps/Linux-deps/include/pngconf.h

# compiling
source /usr/share/GNUstep/Makefiles/GNUstep.sh
make -f Makefile release -j$(nproc)

To my surprise it worked superbly well on my Kali machine! After the script finished without any complaints, I had the Oolite directory and just needed to start oolite.app/oolite.
The version was 1.91 and should be the most recent one.
I need a break now, then I'll try to find out why this one worked and all other attempts did not.

Okay, break over: Used the above script on a Kali machine which has never seen Oolite before, and it worked like a charm. I'd wish I had an option in Oolite to show this monster version & release ID, but I assume it can only be the most recent release which gets installed. In the script there are no references to something else. On the page https://github.com/OoliteProject/oolite.git I do see the code published most lately, so the script should use this and nothing else. Right?

Good you dug this out. Let's compare the script you found (and confirmed it works) with the script that is executed at Github (find the full script here: https://github.com/OoliteProject/oolite ... ll.yml#L65

In excerpts this is what it looks like:

Code: Select all

- name: install all the necessary packages
        run: |
          sudo apt update
          sudo apt -y install git gobjc gnustep-devel make libsdl1.2-dev libvorbis-dev libopenal-dev g++ libespeak-dev libnspr4-dev

- name: Checkout Oolite
        uses: actions/checkout@v4
        with:
          path: oolite
          fetch-depth: 0
          submodules: true

- name: compiling up to installer script (.run file)
        run: |
          cd oolite
          source /usr/share/GNUstep/Makefiles/GNUstep.sh
          make -f Makefile ${{matrix.flavour}} HOST_ARCH=$(uname -m)

From what I can see on Github we omit the png-deletion part. And it might be debatable whether the submodules are fetched in a similar way or not.
But none of these differences should make us miss libgnustep*.* just because it is version 1.28, right?

[Cas Tell]

I'm still trying to understand what's going on here. I have the following plan:
I'll set up several virtual machines with vanilla configurations of Kali, Mint etc. as well as Fedora. The main reason is, that I can always revert to a clean config.
I hope to find out more this way, I need an analytic approach, otherwise things get too complex.

[hiran]

I'm still trying to understand what's going on here. I have the following plan:
I'll set up several virtual machines with vanilla configurations of Kali, Mint etc. as well as Fedora. The main reason is, that I can always revert to a clean config.
I hope to find out more this way, I need an analytic approach, otherwise things get too complex.

I could not agree more. Thank you for taking that effort.
When things get going and you notice the above instructions work on each of the platforms we may try to crosscheck: What happens when Oolite built on one setup is run on another?
So the VMs can act in two roles: build environment and run environment

[hiran]

Btw: how are you creating/recreating these virtual machines? Are you using something to automate the setup?

[Cas Tell]

Btw: how are you creating/recreating these virtual machines? Are you using something to automate the setup?

This is good old keyboard & mouse handcrafting. At the moment I'm downloading the latest Kali version, put it into an ISO pool, which is the basis for the creation of virtual boxes (the Oracle virtualization freeware). Do you think about the creation of runners outside of github?

[hiran]

Btw: how are you creating/recreating these virtual machines? Are you using something to automate the setup?

This is good old keyboard & mouse handcrafting. At the moment I'm downloading the latest Kali version, put it into an ISO pool, which is the basis for the creation of virtual boxes (the Oracle virtualization freeware). Do you think about the creation of runners outside of github?

I am not yet thinking of Github runners, although that might be an option in the long run.
But I have used Virtualbox in combination with Vagrant and Ansible for a long time, until it stopped working on my Ubuntu machine and I am unable to repair it but also reluctant to reinstall my desktop from scratch.

Have you heard about Vagrant? It can help you big time.

[Cas Tell]

I'll have a look at Vagrant, thanks for the hint!
At the moment I only have a 500$ notebook (Asus Zenbook 14) which isn't very powerful , so working with Virtual Box is annoyingly slow. But I hope that I can speed up things a bit by optimizing some settings and do some meaningful testing then. This performance problem is the main hurdle when it comes to virtual machines: The concept is nice but you really have to invest a big chunk of money into powerful hardware to enjoy it. Sometimes real iron is much cheaper than building a performant environment for the virtual machines.

[hiran]

I'll have a look at Vagrant, thanks for the hint!
At the moment I only have a 500$ notebook (Asus Zenbook 14) which isn't very powerful , so working with Virtual Box is annoyingly slow. But I hope that I can speed up things a bit by optimizing some settings and do some meaningful testing then. This performance problem is the main hurdle when it comes to virtual machines: The concept is nice but you really have to invest a big chunk of money into powerful hardware to enjoy it. Sometimes real iron is much cheaper than building a performant environment for the virtual machines.

Core I 7 and 16 GB RAM do not sound underpowered. Assign at least 4 GB RAM and two cores to your Linux VM, reduce the amount of applications running on the host and it should perform better.

[Cas Tell]

The result of today is as follows:
New Kali Linux installation on a virtual machine. Running this file here was an immediate success:

Code: Select all

#!/bin/bash

# install all the necessary packages
sudo apt update
sudo apt -y install \
  git \
  gobjc \
  gnustep-devel \
  make \
  libsdl1.2-dev \
  libvorbis-dev \
  libopenal-dev \
  g++ \
  libespeak-dev \
  libnspr4-dev \
  libpng-dev

# download source and dependencies
git clone https://github.com/OoliteProject/oolite.git
cd oolite
cp .absolute_gitmodules .gitmodules
git submodule update --init
git checkout -- .gitmodules

# this is necessary, as otherwise textures aren't loaded correctly
rm deps/Linux-deps/include/png.h
rm deps/Linux-deps/include/pngconf.h

# compiling
source /usr/share/GNUstep/Makefiles/GNUstep.sh
make -f Makefile release -j$(nproc)

I had to add libpng-dev to the apt install stuff, and the two rm lines are necessary, without them I had no textures at all. But this feature may depend on the given hardware and can't be tested thoroughly on virtual machines, I think.