Oolite Bulletins

So now that we see the correct error messages for a failing Oolite (see https://bb.oolite.space/viewtopic.php?p=290000#p290000), let's now focus on the root cause why Oolite is failing at all.

On a freshly installed Ubuntu 22 LTS system, having installed the current Oolite 1.91 prerelease I get this:
Looks like the executable has a dependency to libgnustepßbase.so.1.28.
I also tested that this problem goes away if I install the current GNUstep libraries:
(here Oolite is on the entrance screen that rotates a Cobra MKIII and allows to start a game, load a savegame etc.

What do we want to do about it, and how may it be resolved?

Noone worried about this issue?
Noone has a proposal?

It could mean I am the only Linux user...

You play on Linux, I'm on the AppleMac, Arquebus makes films, and the others are all beavering away on OXPs or wearing disguise glasses.

Cholmondely wrote: ↑Tue Jul 18, 2023 2:49 pm

You play on Linux, I'm on the AppleMac, Arquebus makes films, and the others are all beavering away on OXPs or wearing disguise glasses.

Then the most suitable answer is "it works for me".

Don’t confuse a lack of response from the Linux community as a lack of interest. It might take a little time for someone to see the post and then investigate their response. They’ll get to it in time.

From what I can tell, there are two obvious options:
1) provide libgnustep-base.so.1.28 instead of libgnustep-base.so.1.20 as a Linux dependency
2) continue building with libgnustep-base.so.1.20 and use it as a runtime dependecy

Number 2 above might require an environment with an Obj-C compiler that can link with that version (I think versions of GCC >= 10 -- or even lower ? -- cannot).

EDIT: there is also a variation of version 2, where a more recent compiled version of libgnustep-base.so.1.20 is replaced (or added as a variant -- there is a precedent for libespeak, with non- and pulse variants) in the dependencies, that would be compiled and allow compilation for more recent versions of GCC.

Commander_X wrote: ↑Wed Jul 19, 2023 12:51 pm

From what I can tell, there are two obvious options:
1) provide libgnustep-base.so.1.28 instead of libgnustep-base.so.1.20 as a Linux dependency
2) continue building with libgnustep-base.so.1.20 and use it as a runtime dependecy

Towards 1 is what I did by installing the required library.
Number 2 likely needs tweaking of the makefiles. I am happy if I can read and guess what they are doing.

Commander_X wrote: ↑Wed Jul 19, 2023 12:51 pm

Number 2 above might require an environment with an Obj-C compiler that can link with that version (I think versions of GCC >= 10 -- or even lower ? -- cannot).

EDIT: there is also a variation of version 2, where a more recent compiled version of libgnustep-base.so.1.20 is replaced (or added as a variant -- there is a precedent for libespeak, with non- and pulse variants) in the dependencies, that would be compiled and allow compilation for more recent versions of GCC.

Seems like we need to review the linux dependencies. I am just not sure which of the two options you listed is better.
Number 2 may have additional caveats as I understand it.

hiran wrote: ↑Wed Jul 19, 2023 6:46 pm

[...]
Number 2 may have additional caveats as I understand it.

I gave a spin to an attempt to rebuild gnustep-base-1.20 in my current Slackware 15.0 version, and it won't work. I tweaked some configuration options (by excluding e.g. objc-api.h, and enforcing the linker to look into /usr/lib64), and it ended with a Makefile without SSL support though, but trying to compile, similar and more references to the previous Obj-C include files started to pop-up. This definitely discourages any attempt to keep 1.20 for compilation in the modern environments.
Definitely, "installing the required library" might not be an easy task for non dnf/yum/rpm or apt/deb distributions. The best bet would be to package a "tested" version as a dependency, the same way 1.20 was distributed.

Commander_X wrote: ↑Wed Jul 19, 2023 8:10 pm

hiran wrote: ↑Wed Jul 19, 2023 6:46 pm

[...]
Number 2 may have additional caveats as I understand it.

I gave a spin to an attempt to rebuild gnustep-base-1.20 in my current Slackware 15.0 version, and it won't work. I tweaked some configuration options (by excluding e.g. objc-api.h, and enforcing the linker to look into /usr/lib64), and it ended with a Makefile without SSL support though, but trying to compile, similar and more references to the previous Obj-C include files started to pop-up. This definitely discourages any attempt to keep 1.20 for compilation in the modern environments.

Ouch. that is uncomfortable, and not even guaranteed to last long.

Commander_X wrote: ↑Wed Jul 19, 2023 8:10 pm

Definitely, "installing the required library" might not be an easy task for non dnf/yum/rpm or apt/deb distributions. The best bet would be to package a "tested" version as a dependency, the same way 1.20 was distributed.

Agree. Let's try that.

Are you familiar with git/github? Could you prepare a change?

hiran wrote: ↑Wed Jul 19, 2023 8:19 pm

[...]
Are you familiar with git/github? Could you prepare a change?

I am familiar a bit with git, but not at all with github.
I don't think though the change is that complicated where the 32 bit and 64 bit of libgnustep-base.so.1.20 are retired (deleted), and libgnustep-base.so.1.28 versions added. The installer should also be adjusted to pick the new version for runtime.

I'd guess the most challenging part would be what brand of the libraries to bring in, Red Hat or Ubuntu/Debian Oh, and also testing the whole new shiny version of Oolite under as many other distributions as possible.

Commander_X wrote: ↑Thu Jul 20, 2023 3:33 am

hiran wrote: ↑Wed Jul 19, 2023 8:19 pm

[...]
Are you familiar with git/github? Could you prepare a change?

I am familiar a bit with git, but not at all with github.
I don't think though the change is that complicated where the 32 bit and 64 bit of libgnustep-base.so.1.20 are retired (deleted), and libgnustep-base.so.1.28 versions added. The installer should also be adjusted to pick the new version for runtime.

I'd guess the most challenging part would be what brand of the libraries to bring in, Red Hat or Ubuntu/Debian Oh, and also testing the whole new shiny version of Oolite under as many other distributions as possible.

Maybe we have less choices over time.

32 bit platforms are loosing support. Ubuntu Desktop is only available for 64 bits. Even a Raspberry Pi has a 64 bit CPU nowadays.

Red Hat vs Ubuntu/Debian: if we build on Github the only Linux they provide is Ubuntu. Either we'd have to build inside Docker or provide our own Runners.

Until someone gets active here we are limited to Ubuntu 64 bits.

So we could compare today's distro-agnostic packaging:
Snap
AppImage
FlatPak

with what we (used to) have:
rpm
deb
autoinstaller (.run)

Right now only the autoinstaller seems to work for Linux.