Unresolved external symbols after update to 1.1.3
Opened this issue · 5 comments
= note: liblibpng_sys-1801e59cb45537ea.rlib(pngread.o) : error LNK2019: unresolved external symbol inflateEnd referenced in function png_destroy_read_struct
liblibpng_sys-1801e59cb45537ea.rlib(png.o) : error LNK2019: unresolved external symbol inflateReset referenced in function png_reset_zstream
liblibpng_sys-1801e59cb45537ea.rlib(pngrutil.o) : error LNK2001: unresolved external symbol inflateReset
liblibpng_sys-1801e59cb45537ea.rlib(png.o) : error LNK2019: unresolved external symbol adler32 referenced in function png_compare_ICC_profile_with_sRGB
liblibpng_sys-1801e59cb45537ea.rlib(png.o) : error LNK2019: unresolved external symbol crc32 referenced in function png_calculate_crc
liblibpng_sys-1801e59cb45537ea.rlib(pngrutil.o) : error LNK2019: unresolved external symbol inflate referenced in function png_inflate
liblibpng_sys-1801e59cb45537ea.rlib(pngrutil.o) : error LNK2019: unresolved external symbol inflateReset2 referenced in function png_inflate_claim
liblibpng_sys-1801e59cb45537ea.rlib(pngrutil.o) : error LNK2019: unresolved external symbol inflateInit2_ referenced in function png_inflate_claim
liblibpng_sys-1801e59cb45537ea.rlib(pngrutil.o) : error LNK2019: unresolved external symbol inflateValidate referenced in function png_inflate_claim
liblibpng_sys-1801e59cb45537ea.rlib(pngwrite.o) : error LNK2019: unresolved external symbol deflateEnd referenced in function png_destroy_write_struct
liblibpng_sys-1801e59cb45537ea.rlib(pngwutil.o) : error LNK2001: unresolved external symbol deflateEnd
liblibpng_sys-1801e59cb45537ea.rlib(pngwutil.o) : error LNK2019: unresolved external symbol deflate referenced in function png_compress_IDAT
liblibpng_sys-1801e59cb45537ea.rlib(pngwutil.o) : error LNK2019: unresolved external symbol deflateReset referenced in function png_deflate_claim
liblibpng_sys-1801e59cb45537ea.rlib(pngwutil.o) : error LNK2019: unresolved external symbol deflateInit2_ referenced in function png_deflate_claim
C:\Users\travis\build\aleksijuvani\polygonist-rs\target\debug\examples\multiple_windows-9329158863b8ecdf.exe : fatal error LNK1120: 12 unresolved externals
That's a problem with linking of zlib, not libpng. This crate doesn't handle zlib itself, but relies on https://github.com/rust-lang/libz-sys
Try set LIBZ_SYS_STATIC=1 or make sure you have Microsoft's vcpkg installed, and zlib package for it, that matches your architecture.
Or even better, stay away from libpng, because it's just an endless pain. Use lodepng crate, which is a pure Rust library and doesn't have such issues.
Sorry about the lackluster issue description yesterday. I didn't have the energy to investigate this issue further since I figured it could've been a simple configuration mishap during the packaging process of the new version, and would not require me to write a lengthy description.
To be clear, the previous version of libpng-sys links fine. I'm not sure why an update to this crate would cause the program to fail to link with zlib. There haven't been any updates to libz-sys. I'm also able to reproduce the issue on macOS. I would prefer to stick with libpng because it's much more performant than the alternatives that I've looked at, and I haven't had any trouble with it before.
As an additional clue, I seem to have the "static" feature enabled for this crate, which I think was necessary to get it to link on Windows in the first place. Removing this feature will enable the new version to link successfully under macOS, but will still cause it to fail under Windows (however with different symbols, which is a different issue that made me enable the "static" feature in the first place). I have the zlib package installed on vcpkg. LIBZ_SYS_STATIC=1 does not seem to help on either platform.
the zlib part hasn't changed between versions. It's only a security update of libpng from 1.6.36 to 1.6.37, so I don't expect it to change anything about dependencies in such a small update either.
I was looking at the changelog for 1.6.37 earlier and there were some changes made to the Makefiles specifically, but I'm not sure if this matters.
It doesn't, because this crate doesn't use makefiles.