libpng12 (Ubuntu 16.04 default) is too old

[dreamer]

When implementing release builds I presumed libpng12 will be available everywhere while libpng16 might be missing… as it turns out, the opposite might be true.

It seems like libpng12 is available everywhere… except Ubuntu > 16.04… And some packages might bundle their own copies of libpng12 so that might result in the package working for some users and failing for others.

It seems like most distributions transitioned to libpng16 by default due to security issues.

I need to investigate what package is pulled by SDL or preinstalled by default on major distributions and adjust our scripts and instructions accordingly.

[dreamer]

Just got confirmation that it's a problem on default installation of Debian Sid as well. So the current installation instructions in README.md are incorrect for many users.

[kcgen]

Great we got feedback so quickly; fail fast, like they say.

[dreamer]

This issue is Linux, or maybe even Ubuntu-specific.

We already knew, that libsdl somehow depends on libpng… and now we know why. SDL1.2 depends on libcaca, which in turns depends on libpng. Unfortunately, on Ubuntu 16.04 that dependency is fixed to libpng1.2 (SDL1.2 dev and libpng1.6 dev packages cannot be installed at the same time in the result).

This is rather bad, as we do not care about any functionality provided by libcaca but are held back because of it. SDL2 does not have this problem - it dropped libcaca dependency, so #29 will resolve the conundrum.

As far as I can tell, we have following options:

1. Switch release builds to Ubuntu 18.04 - it would be easy solution, but it'll introduce "known unknown" problems: Will users of 16.04 LTS and all dependencies (Mint LTS) be able to run it? I suspect libstdc++ might start being a problem once we'll do this.
2. Do nothing until SDL2 is merged-in; SDL2 does not have such limitations - it will also enable builds without libpng installed. (but this is not an immediate solution). Also, I am worried about users of new Ubuntus, which might be missing libpng1.2 in system packages.
3. Disable screenshot functionality for our Linux release builds; then re-enable it in PR bringing-in SDL2.

@krcroft what do you think? I would go with (3)

[kcgen]

I also prefer (3) because it disconnects DOSBox from directly using libpng and/or a specific version of libpng. We still directly depend on SDL 1.2, however the user's operating system (however new or old it might be), is free to bring in whatever baggage is needed to satisfy SDL 1.2 - be it libpng 1.2/1.5/1.6, libcacca, and so on.

Another option is static linking. SDL 1.2 is long past its support period and now frozen in time, so modern benefits of dynamic linking (like getting new security/bug/performance fixed libraries) are lost with SDL 1.2. (For SDL 2, dynamic linking makes great sense as the community is still plowing fixes into it while retaining API compatibility).

The static option also lets us hand-pick the newest libPNG and "best" SDL 1.2 (containing the post-1.2 fixes that Ryan and team have sitting in their mercurial repo, now many years old), which maybe some old distros haven't picked up. So a static binary would give those user only older systems a better experience.

I think the way to do a static build is add more contrib/ makefiles like we have for OpusFile. But that's some work and not an immediate fix.

So definitely agree to go with (3).