Unresolved externals despite linking in zlib.lib

Question

I\'ve been trying to compile an application which utilizes zlib compression in VC++ 2010.

I get the

error LNK2019: unresolved external symbol _infla         


        

Answer 1

You compiled the zlib static library using something other than VC++ 2010?

Is this a recent upgrade from VS2008/05?

Have you tried recompiling the static library using the 2010 toolset?

Answer 2

I ran into the same problem myself using Visual Studio 2017. I got error messages like:

error LNK2019: unresolved external symbol __imp__deflate referenced in function 
error LNK2019: unresolved external symbol __imp__deflateEnd referenced in function 
error LNK2019: unresolved external symbol __imp__inflate referenced in function 
error LNK2019: unresolved external symbol __imp__inflateEnd referenced in function 
error LNK2019: unresolved external symbol __imp__deflateInit2_ referenced in function
error LNK2019: unresolved external symbol __imp__inflateInit2_ referenced in function

I followed the tip from Michael Burr, checking if the zlib file I had contained these methods:

dumpbin /symbols zlib.lib

The output showed the methods were there, yet Visual Studio still complained. Ultimately I downloaded the latest stable release of zlib from their github repository, and then compiled it (using a Visual Studio Developer Console). Their instructions were not directly helpful though eventually I found their MS Makefile which contained the command I needed to run.

nmake -f win32/Makefile.msc

Have a look inside their win32/Makefile.msc file for more information on the building process.

The build process generated two .lib files. What I really needed in my project was the one called 'zdll.lib'. (See their documentation file DLL_FAQ.txt for info on it). Back inside Visual Studio, I had to manually add the file to my project (NOT using the Linker --> General --> Additional Library Directories method, since this triggered the other problems.) You can add them by Right-Clicking on the Solution Object (Not the topmost item in the list, but the second item. In the picture below, my project is called Lasso, so you would want to click on the equivalent in your project.)

Go to: Add --> Existing Item...

Then select the generated zdll.lib file.

Lib files explicitly added to Visual Studio project

Answer 3

In my case I amended

• Config -> Linker -> Input -> Additional Dependencies

to read ucrt.lib;vcruntime.lib;msvcrt.lib;kernel32.lib

This enabled libz to build under Windows 10 with VS2015

Ensuring the build type was /MD

This was also the case if building for libpng (that requires zlib), the same modifications enable successful building with the old included default 'projects' files.

Answer 4

If you are using the VS2010 solution provided in contrib/ be aware that it's bugged. The zlibstat project defines ZLIB_WINAPI which according to zlib FAQ is used to switch on the STDCALL convention. Just remove it from the project settings and recompile the lib.

Answer 5

Be aware that the order of the libraries matters. Suppose you want to link A.OBJ, B.LIB, and C.LIB, with the input files specified in this order. If C.LIB calls a function in B.LIB, it won't be found (unless it was already fortuitously called from A.OBJ).
Could this be the source of your problem?

Answer 6

A few shot-in-the-dark suggestions:

Try running dumpbin /symbols zlib.lib to see if the symbols in that lib are as you expect (ie., is inflateInit2 in there?).

If the build is currently relying on a lib path search to locate zlib.lib, try specifying the full absolute path to the library to rule out the linker finding some stale zlib library somewhere else on your system.

Also, post the command line used for the linker (from the build log file).

Update:

You can see behavior like this if you're accidentally mixing 32-bit and 64-bit components (ie., the zlib.lib file is built for x86 and the application is being built for x64). The linker doesn't complain about not finding the lib file, nor does it complain that the objects in the lib file are for a different platform. Given that your error message mentions a symbol without any decoration, I'd bet that the linker is building an x64 application, but maybe the zlib.lib has x86 objects (and therefore there's a symbol named _inflateInit2 in there, decorated with an underscore or maybe something else).

(as an aside - I wonder if it's possible to mix x86 and x64 objects in the same lib file as long as the have different names. Not that I want to actually do this).