Official Simutrans-Extended does not run on many Linux distributions

[Matthew]

Steps to reproduce

1. Use a Debian-based Linux distribution from the last few years (I used Ubuntu 20.04 and a clean install of Kubuntu 21.10).
2. Download the ZIP file containing a complete Simutrans-Extended installation, including the latest Nightly Linux executable, from Bridgewater-Brunel.
3. Extract the ZIP file into your home directory or another suitable location.
4. Open a terminal and run: ./simutrans-extended

Expected behaviour
Simutrans-Extended starts

Observed behaviour
Simutrans-Extended returns the following error message:

Code Select Expand

./simutrans-extended: error while loading shared libraries: libpng15.so.15: cannot open shared object file: No such file or directory

Notes
This error message seems to indicate that the executable on B-B is compiled to use libpng 1.5. The libpng page on Repology suggests that every major Linux distribution has long since switched to libpng 1.6. For example, Debian and its derivatives (Ubuntu, Mint, etc.) switched to 1.6 in January 2014. Fedora switched around the same time. Arch updated in March 2013.

A few distributions have a libpng15 compatibility package for older applications that still expect it; the most important are Fedora and openSUSE. But the data above suggests that the Sim-Ex executable published on B-B does not currently run on any Debian-based distribution. (Testing by other players would be helpful)

Roboron kindly suggested redirecting libpng15.so.15 to point to libpng16.so.16, but this does not work: some part of Simutrans is checking libpng's internal version number and will only accept 15.

But when I compile Sim-Ex myself on Ubuntu 20.04, it uses libpng 1.6. I don't remember any special action on my part to get this working. So I guess it is just picking up the version of libpng supplied with Ubuntu 20.04?

It seems plausible that the B-B build process has somehow got stuck on libpng 1.5; perhaps it was the latest version when the server was set up?

Possible fix?
This is summary of a Discord discussion where Roboron concluded that if libpng 1.5 was removed from B-B then the builds should pick up and use Ubuntu's standard libpng16. He is far better placed than me to talk about these things, but that would be consistent with my experience. If I was making that kind of change I would definitely test it immediately, rather than waiting until the next Nightly build, but again you (James) have ten thousand times more experience than me with this.

It would be possible to ask every user of a Debian-based distribution to find and install libpng 1.5, but this seems a unnecessary barrier to new players given that it appears to be B-B that has (no doubt for good reasons!) diverged from the mainstream.

[prissi]

libpng 15 has some bugs, so it would make also sense to update to libpng 16.

(Also I hope the BB sever run a distribution newer than from 2014 ... )

[O01eg]

It works if you build it for required distributive. "Official" Linux binary distribution is expected to include dependencies with it.

[Roboron]

While this was happening to Extended, Standard got its distribution revised to include dependencies, essentially solving this and other related problems (see https://forum.simutrans.com/index.php/topic,21324.msg199031/topicseen.html ).

This could be ported to Extended if there is demand, although it was done for the CMake build system which B-B does not use (but the GitHub Actions do).

[prissi]

Alternatively, the standard Makefile STATIC:=1 build only need SDL2 freetype (and if enabled) fluidsynth as dependencies, so this might also help. Because if BB runs and older Debian, the standard cmake build may fail, because Debians cmake would be too old.

[jamespetts]

Thank you for the report. I have amended the build configuration on the server, which I think may effect a resolution to this. I should be grateful if somebody could test and report back with to-morrow's nightly build. Thank you.

[Matthew]

Thank you for the report. I have amended the build configuration on the server, which I think may effect a resolution to this. I should be grateful if somebody could test and report back with to-morrow's nightly build. Thank you.

The Nightly build now works on my installation of Ubuntu 20.4.3. So that's progress, thank you!