-
Notifications
You must be signed in to change notification settings - Fork 39
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Prevent link to zlib1.dll #72
base: dev
Are you sure you want to change the base?
Conversation
This is maybe a dumb question, but... do we actually still use libpng anywhere? I think it was originally a dependency of SDL_image, but I think SDL_image is now using stb_image instead of libpng ever since the version bump. Is it used anywhere else? What happens if we remove libpng completely, does anything fail to link? |
Also even if SDL_image is still using libpng (maybe for saving files?), I think it'll be the vendored one now. |
zlib is still required by core RGSS (since the stock engine statically bundles the zlib gem) |
I did a quick test and freetype is still using libpng. |
zlib is still there, just not the dll. Do we absolutely need the dll? I've been playing a game for a while now and it's running just fine. |
Hmm, is the issue that libpng's build system assumes dynamic linking to zlib? If so, does libpng support some kind of configure flag to statically link to zlib? If they do not, would it be feasible to ask upstream libpng to support that? |
The biggest problem is that I just don't know enough. Which makes it especially hard for me to be telling people how to fix their stuff. It's likely I'm just not familiar with all the necessary syntax and systems that are in use. The last commit on the mkxp-z fork of libpng, which changed the line causing the dynamic link, says "zlib should be injected only when pkgconfig is ran with the --static option." which I tried and nothing changed. The executable still ended up with the zlib1.dll dependency. I did this post "make install" and post "source vars.sh". meson.build looks like it's already configured to build it statically so I have no other ideas. |
Let's wait a little while on this one. There's going to be an SDL_ttf version bump soon, and I suspect that we might be able to avoid the libpng/zlib dependency from freetype if we tell SDL_ttf to use its vendored freetype (similar to how we now use vendored deps in SDL_image). So maybe this PR will become irrelevant at that point. If it doesn't, we can come back to this. |
(Marked this as a draft to reflect that this will be re-evaluated after SDL_ttf is bumped.) |
Honestly, I hate that I've had to resort to sed to accomplish this but I couldn't find another way, other than directly changing the libpng repository. If this solution isn't good enough, I completely understand.
In any case, I've tested it thoroughly; zlib now just links statically as intended, and zlib1.dll is no longer required.