[Zlib-devel] Fwd: zlib 1.2.4 linker with gz functions

John Bowler jbowler at frontiernet.net
Mon Apr 19 13:37:33 EDT 2010


In addition to what William said:

> error LNK2001: unresolved external symbol __imp__gzclose at 4
> CDRFileCracker.obj : error LNK2001: unresolved external symbol __imp__gzread at 12
> CDRFileCracker.obj : error LNK2001: unresolved external symbol __imp__gzopen at 8

Those are '__stdcall' symbols, but the official library is built with '__cdecl' as the calling convention.  (The symbols in zdll.lib are '__imp__gzopen' and '_gzopen').  I think MSVC can fix this up if it encounters it, but it suggests that either:

1) The project was built with -DZLIB_WINAPI (and this is *wrong* for the official build.) or;
2) The project was built with /Gz (use __stdcall as the default)

(2) is a bit of a problem - zlib.h/zconf.h for the official DLL should record the actual calling convention used.

From: William A. Rowe Jr.
>The ZLIB_DLL macro must not be used.  They need to remove that definition from
>their code project, recompile and attempt to relink all of their consuming code.

Well... zlib.h says:

"If building or using zlib as a DLL, define ZLIB_DLL."

And it doesn't seem to do any harm - it just sets __declspec(dllimport), and that's correct for the official build.

Shouldn't the official build distribute a 'zconf.h' with all the *unsettable* options zapped?  If there is some reason for not setting ZLIB_DLL (when linking to a DLL) remove it, remove ZLIB_WINAPI, set ZEXPORT to __cdecl etc.

John Bowler <jbowler at acm.org>






More information about the Zlib-devel mailing list