Recurrent issues with zlib1.dll on Windows

This issue was already solved, but I want to sum it up and document its outcome. Devs might find this a suitable place when looking for an answer in case of future crashes, or use this page to describe any follow-up actions taken.

To make this easier to discover through a GH search, I'm copy-pasting the most notable error message:

[error] SDLScreenManager.cpp:159 rd::SDLScreenManager::initSDL(): SDL_image could not initialize! SDL_image Error: Failed loading libpng16-16.dll: The specified procedure could not be found.

On-screen prompts will additionally mention a missing entry point and a function name. Indirectly, all of this boils down to problems with zlib1.dll, which is a basic dependency for:

SDL_image
SDL_ttf
ZBar

You'll find a copy of this DLL when downloading the binaries of each package listed above. It's known to introduce version mismatches on runtime:

As we are now aware of, ZBar (official package) is shipped with a quite-old version of zlib1.dll.
SDL2 subprojects (image, ttf) are compiled against newer iterations of this library.
Within SDL2 itself, image has been reported to differ from ttf as to the latest version used.

Symptoms of the above have been pictured in the error message incidentally pointing at libpng16-16.dll, but the main friction point here is clearly the zlib1.dll thing. It's vital to proceed with care while configuring the search paths for DLLs AND when moving the binaries around:

Always place the ZBar binary location last in the PATH (with respect to other RD dependencies, notably the SDL2 libs).
Certain users will prefer to split SDL2 stuff in subdirectories dedicated for each subproject (image, ttf, mixer, and the core library). As of SDL_image v2.0.2 and SDL_ttf v2.0.14, the former calls methods from zlib1.dll that didn't make their way to the DLL distributed along with the latter, yet. That is, you need to make sure that you place first in the PATH the directory pointing at the latest zlib1.dll available (take a look in the Properties context menu).
Other people will tend to work with a single directory for SDL2-related files (that's how we proceed ATM on AppVeyor CI builds), merging subfolders together (include/, lib/ and so on). Clashes will surely occur: on a windowed environment, the user would be prompted to choose which file to preserve when two files share the same name. As explained before, keep the most recent zlib1.dll, overwrite the other.

I discovered that the system PATH may spoil any improvements on the user PATH since it's evaluated in the first place. I ran into this because there was another zlib1.dll in MinGW/bin, which in turn was set by the system itself and could not be modified through the Control Panel. You'd have to resort to manually tweaking the PATH via command-line (always prepend new values instead of appending them).

Another option is to copy that DLL to the corresponding working directory (usually the same as where the game executables are located at). Ongoing work on CPack will take this into account and bundle all necessary binaries with the game files.

Dependency Walker is the recommended tool for debugging these issues. Refer to comments at #95 for further background.

asrob-uc3m / robotDevastation

Recurrent issues with zlib1.dll on Windows #111