Building Oolite 4 Linux

[hiran]

...
And I believe that some of the libraries - as they are compiled against or bundled from a Ubuntu 8 installation have that old glibc version as a dependency. One of which is no longer compatible with today's kernels.
...

Could you, please, elaborate on that?
Have we reached a distro where Oolite for Linux cannot be executed due to the old glibc version dependency?

Actually I have no proof.
But then, since we are building on recent linux (Ubuntu 20, meanwhile Ubuntu 22) neither tsoj nor my were able to run this on e.g. Fedora or CentOS.

Right now I am unsure how to fully repeat your build structure as it would require Ubuntu 8. Github does not offer any runners with that ancient OS.

[Getafix]

...
But then, since we are building on recent linux (Ubuntu 20, meanwhile Ubuntu 22) neither tsoj nor my were able to run this on e.g. Fedora or CentOS.

Right now I am unsure how to fully repeat your build structure as it would require Ubuntu 8. Github does not offer any runners with that ancient OS.

The root cause for not being able to run this on other distros is not (for the time being) the old glibc, and you don't need Ubuntu 8 to repeat my build structure.

A. The root cause is that when "making" the oolite binary, the linker is binding all the external references to the libraries that are delivered with your distro.
B. Unfortunately, each distro, builds its libraries in a custom way using a choice of build options that usually differ from distro to distro (even subtly changing its name sometimes ). Furthermore, not necessarily all distros deliver the same version of a library. This results in incompatible versions of libraries between each distro (and between different releases of the same distro).[/list]

The way to proceed is
1. select a base Linux distro release that will provide you with the necessary development tools and with a glibc version ensuring a balance between backward and forward compatibility (i.e. longevity timespan relative to today). I would suggest an LTS debian-based release, as it is usually a good candidate providing stability and compatibility. However, you need to consider which release to select. The newer the release the less backward compatibility you get. The older the release the less forward compatibility you get.
2. make-install from source all the libraries that can be found in /deps/Linux-deps/x86_64/lib/.
3. copy the new library binaries in /deps/Linux-deps/x86_64/lib/.
4. make Oolite universal installer
5. Try Oolite with various Linux distros and update library list (to built from source) if crashes due to missing libraries exist

This must be done, once for 64bit architectures and once for 32bit architectures. I had two VMs for that; one 64bit and one 32bit. However, I know that it is possible to produce 32bit binaries on a 64bit host. I never managed to achieve this economy though. If the way to go is with two VMs, then the base O/S release must also have a 32bit version.

The tough part, back then when I started the attempt, was to identify the subset of libs needed to be packaged with Oolite installer, while testing in a multitude of distros. This is now mostly done. I say "mostly" because perhaps some new deps may come up due to newer distro.

[hiran]

The root cause for not being able to run this on other distros is not (for the time being) the old glibc, and you don't need Ubuntu 8 to repeat my build structure.

A. The root cause is that when "making" the oolite binary, the linker is binding all the external references to the libraries that are delivered with your distro.
B. Unfortunately, each distro, builds its libraries in a custom way using a choice of build options that usually differ from distro to distro (even subtly changing its name sometimes ). Furthermore, not necessarily all distros deliver the same version of a library. This results in incompatible versions of libraries between each distro (and between different releases of the same distro).[/list]

I can agree to that. Just wondering if each distro comes with it's specialities (otherwise there would be no point for running that distro, right ), how to overcome that. But reading on...

The way to proceed is
1. select a base Linux distro release that will provide you with the necessary development tools and with a glibc version ensuring a balance between backward and forward compatibility (i.e. longevity timespan relative to today). I would suggest an LTS debian-based release, as it is usually a good candidate providing stability and compatibility. However, you need to consider which release to select. The newer the release the less backward compatibility you get. The older the release the less forward compatibility you get.
2. make-install from source all the libraries that can be found in /deps/Linux-deps/x86_64/lib/.
3. copy the new library binaries in /deps/Linux-deps/x86_64/lib/.
4. make Oolite universal installer
5. Try Oolite with various Linux distros and update library list (to built from source) if crashes due to missing libraries exist

This must be done, once for 64bit architectures and once for 32bit architectures. I had two VMs for that; one 64bit and one 32bit. However, I know that it is possible to produce 32bit binaries on a 64bit host. I never managed to achieve this economy though. If the way to go is with two VMs, then the base O/S release must also have a 32bit version.

The tough part, back then when I started the attempt, was to identify the subset of libs needed to be packaged with Oolite installer, while testing in a multitude of distros. This is now mostly done. I say "mostly" because perhaps some new deps may come up due to newer distro.

So GitHub offers us these hosted runners:
https://docs.github.com/en/actions/usin ... d-software
You can see that Linux-wise there is just Ubuntu 20 and Ubuntu 22. Following your hints I'd probably go for the older one.

Regarding 32 and 64 bits: When we focus on normal desktop hardware, since quite some years it is getting difficult to buy 32 bit hardware. Also it is not offered by GitHub. Also Ubuntu.com no longer offers 32 bits for their current versions. So unless someone screams for it and provides some resources (such as supporting a dedicated runner) I will ignore that completely.

But we never cared for steps 2 and 3. That is for sure something we can look into.