We are currently migrating Bugzilla to GitHub issues.
Any changes made to the bug tracker now will be lost, so please do not post new bugs or make changes to them.
When we're done, all bug URLs will redirect to their equivalent location on the new bug tracker.

Bug 4010

Summary: Version of zlib1.dll included with SDL_ttf out-of-sync with version built with SDL_image
Product: SDL_ttf Reporter: Joe LeVeque <joeleveque>
Component: miscAssignee: Sam Lantinga <slouken>
Status: NEW --- QA Contact: Sam Lantinga <slouken>
Severity: normal    
Priority: P2 CC: mail
Version: 2.0.8   
Hardware: x86   
OS: Windows 10   

Description Joe LeVeque 2017-12-26 20:23:55 UTC 
With the recent addition of up-to-date "pristine" versions of external library source code in SDL_image, SDL_image is now building a newer version of zlib1.dll than the version of the DLL that is included with SDL_ttf.

When I build all SDL* libraries and copy all related DLLs to my project path, if I overwrite the newer SDL_image-built DLL with the version from SDL_ttf, I get a runtime error stating "The procedure entry point inflateValidate could not be located in the dynamic link library libpng16-16.dll."

Previously, it did not matter which version of zlib1.dll was copied last, as both versions of the DLL were the same in both projects.

SDL_image and SDL_ttf should always build/supply the same version of any shared DLLs.

I don't use Mercurial much, but if there was a way to share external source code between projects in Mercurial (a la "submodules" in Git), this would allow you to update the external library source code in only one place and any libraries that rely on it would always build the same version. Just a suggestion.
Comment 1 N. de Jonge 2018-02-07 12:30:01 UTC 
I just ran into the exact same problem but with 2.0.7 when building for Windows using mingw. Since "i" (SDL2_image) comes before "t" (SDL2_ttf) in the alphabet, I overwrote SDL2_image's zlib1.dll when copying files. To make things more unfortunate, the inflateValidate error does not show up when testing with Wine. (Which meant my content provider started caching a ZIP with an invalid zlib1.dll to users, and now I'll be shipping an incorrect zlib1.dll for the next day or so.)