Unresolved Externals Despite Linking in Zlib.Lib

Zlib linker error on vs2010

This sounds to me like a mismatch of the symbols in your zlibstatic.lib vs. what you are looking for
in through your include.
Please try:

1. Open a command prompt on windows

2. change to C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\bin
   (or your VS install directory)

3. execute vcvars32.bat

4. dumpbin zlibstatic.lib /symbols > symbols.txt

5. check the symbols.txt for deflateEnd, deflate, and deflateInit

my output looks like this:

026 00000AA0 SECT4  notype ()    External     | _deflate
011 00000000 UNDEF  notype ()    External     | _deflateInit_
02C 00001AC0 SECT4  notype ()    External     | _deflateEnd

my guess is that your dumpbin output looks the same as mine.
Now compare my output to your missing symbols

Your missing symbols: _deflateEnd@4, _deflate@8 and deflateInit@16

The @X postfix gives me a hint that your code is looking for the function in standard calling conventions
but your library is built using the c calling convention.

void _cdecl deflate();      // ==> _deflate
void __stdcall deflate();   // ==> _deflate@8

Try including "zlib.h" without ZLIB_WINAPI defined but ultimatily dumping the symbols with dumpbin should give you a clue.

Another possiblity - you may have compiled zlibstatic.lib with #define Z_PREFIX

C++ Unresolved external symbol when using wofstream

Short: MSVCPRT.LIB

These symbols are defined in C++ Runtime Library. Although you do link with MSVCRT.lib (note the absence of letter P), that's only C, not C++ runtime.

And here is MSDN page you may find useful http://msdn.microsoft.com/en-us/library/abx4dbyh.aspx

Getting unresolved external symbol error with CMake and Visual Studio

If I'm understanding this correctly, then you're trying to pass DLL files to the linker. You cannot link a DLL directly in this way. You will need an import library to link against your DLL. Most likely, your Allegro build already comes with such an import library.

Also, consider using an IMPORTED library target for a more modern approach to represent the Allegro library inside your CMake build. For example:

add_library(Allegro SHARED IMPORTED)
set_target_properties(Allegro PROPERTIES
    IMPORTED_LOCATION "${DEPENDENCIES_DIR}/allegro/bin/allegro.dll"
    IMPORTED_IMPLIB "${DEPENDENCIES_DIR}/allegro/lib/allegro.lib"
    INTERFACE_INCLUDE_DIRECTORIES "${DEPENDENCIES_DIR}/allegro/include"
)

and then you just use it like

target_link_libraries(core … Allegro)

The nice thing about this approach is that it allows you to set up the library in one place and then just use it. No need to explicitly deal with separate variables for different kinds of libs and include directories and preprocessor definitions and whatnot at every point where you want to have something use the library. Linking an imported library target that has been set up like that will automatically cause the necessary include directories etc. to be configured…

What is an undefined reference/unresolved external symbol error and how do I fix it?

Compiling a C++ program takes place in several steps, as specified by 2.2 (credits to Keith Thompson for the reference):

The precedence among the syntax rules of translation is specified by the following phases [see footnote].

1. Physical source file characters are mapped, in an implementation-defined manner, to the basic source character set
   (introducing new-line characters for end-of-line indicators) if
   necessary. [SNIP]
2. Each instance of a backslash character (\) immediately followed by a new-line character is deleted, splicing physical source lines to
   form logical source lines. [SNIP]
3. The source file is decomposed into preprocessing tokens (2.5) and sequences of white-space characters (including comments). [SNIP]
4. Preprocessing directives are executed, macro invocations are expanded, and _Pragma unary operator expressions are executed. [SNIP]
5. Each source character set member in a character literal or a string literal, as well as each escape sequence and universal-character-name
   in a character literal or a non-raw string literal, is converted to
   the corresponding member of the execution character set; [SNIP]
6. Adjacent string literal tokens are concatenated.
7. White-space characters separating tokens are no longer significant. Each preprocessing token is converted into a token. (2.7). The
   resulting tokens are syntactically and semantically analyzed and
   translated as a translation unit. [SNIP]
8. Translated translation units and instantiation units are combined as follows: [SNIP]
9. All external entity references are resolved. Library components are linked to satisfy external references to entities not defined in the
   current translation. All such translator output is collected into a
   program image which contains information needed for execution in its
   execution environment. (emphasis mine)

[footnote] Implementations must behave as if these separate phases occur, although in practice different phases might be folded together.

The specified errors occur during this last stage of compilation, most commonly referred to as linking. It basically means that you compiled a bunch of implementation files into object files or libraries and now you want to get them to work together.

Say you defined symbol a in a.cpp. Now, b.cpp declared that symbol and used it. Before linking, it simply assumes that that symbol was defined somewhere, but it doesn't yet care where. The linking phase is responsible for finding the symbol and correctly linking it to b.cpp (well, actually to the object or library that uses it).

If you're using Microsoft Visual Studio, you'll see that projects generate .lib files. These contain a table of exported symbols, and a table of imported symbols. The imported symbols are resolved against the libraries you link against, and the exported symbols are provided for the libraries that use that .lib (if any).

Similar mechanisms exist for other compilers/ platforms.

Common error messages are error LNK2001, error LNK1120, error LNK2019 for Microsoft Visual Studio and undefined reference to symbolName for GCC.

The code:

struct X
{
   virtual void foo();
};
struct Y : X
{
   void foo() {}
};
struct A
{
   virtual ~A() = 0;
};
struct B: A
{
   virtual ~B(){}
};
extern int x;
void foo();
int main()
{
   x = 0;
   foo();
   Y y;
   B b;
}

will generate the following errors with GCC:

/home/AbiSfw/ccvvuHoX.o: In function `main':
prog.cpp:(.text+0x10): undefined reference to `x'
prog.cpp:(.text+0x19): undefined reference to `foo()'
prog.cpp:(.text+0x2d): undefined reference to `A::~A()'
/home/AbiSfw/ccvvuHoX.o: In function `B::~B()':
prog.cpp:(.text._ZN1BD1Ev[B::~B()]+0xb): undefined reference to `A::~A()'
/home/AbiSfw/ccvvuHoX.o: In function `B::~B()':
prog.cpp:(.text._ZN1BD0Ev[B::~B()]+0x12): undefined reference to `A::~A()'
/home/AbiSfw/ccvvuHoX.o:(.rodata._ZTI1Y[typeinfo for Y]+0x8): undefined reference to `typeinfo for X'
/home/AbiSfw/ccvvuHoX.o:(.rodata._ZTI1B[typeinfo for B]+0x8): undefined reference to `typeinfo for A'
collect2: ld returned 1 exit status

and similar errors with Microsoft Visual Studio:

1>test2.obj : error LNK2001: unresolved external symbol "void __cdecl foo(void)" (?foo@@YAXXZ)
1>test2.obj : error LNK2001: unresolved external symbol "int x" (?x@@3HA)
1>test2.obj : error LNK2001: unresolved external symbol "public: virtual __thiscall A::~A(void)" (??1A@@UAE@XZ)
1>test2.obj : error LNK2001: unresolved external symbol "public: virtual void __thiscall X::foo(void)" (?foo@X@@UAEXXZ)
1>...\test2.exe : fatal error LNK1120: 4 unresolved externals

Common causes include:

• Failure to link against appropriate libraries/object files or compile implementation files
• Declared and undefined variable or function.
• Common issues with class-type members
• Template implementations not visible.
• Symbols were defined in a C program and used in C++ code.
• Incorrectly importing/exporting methods/classes across modules/dll. (MSVS specific)
• Circular library dependency
• undefined reference to `WinMain@16'
• Interdependent library order
• Multiple source files of the same name
• Mistyping or not including the .lib extension when using the #pragma (Microsoft Visual Studio)
• Problems with template friends
• Inconsistent UNICODE definitions
• Missing "extern" in const variable declarations/definitions (C++ only)
• Visual Studio Code not configured for a multiple file project
• Errors on Mac OS X when building a dylib, but a .so on other Unix-y systems is OK

zlib linking errors

Oops!! I forgot to make them.
Use make -f win32/Makefile.borand it's done!!

Working fine so far!!!!
Also, don't forget to add dependencies!

Static ZLIB (1.2.8) linking on Visual Studio 2012

I have finally managed to solve my problem. For those that end up in such a problem, heres how to solve it:

If you followed the tutorial in my first post, you would have removed ZLIB_WINAPI from the zlibstat project's Preprocessor. However, after setting up my own project (setting ZLIB dependencies path, LIB dependencies libraries etc) that uses ZLIB, I 'accidently' included/defined the damned ZLIB_WINAPI macro in the header file I'm using ZLIB, right before including "zlib.h".

One curious thing about this is that when launching the app on debug mode (which was using dynamic linking), everything succeeded and worked like a charm, without any warnings or whatsoever, HOWEVER, on release mode (which was using the static linking), it crashed.

So, to clear things up, the tutorial tells us to remove the ZLIB_WINAPI preprocessor from the zlibstat project, which produces the static lib, whilst the zlibvc project has the ZLIB_WINAPI in its preprocessor. In other words, that means that if we're using different linkings for each configuration (debug/release), we have to add the ZLIB_WINAPI macro or not!

Define the ZLIB_WINAPI macro before including "zlib.h" if youre using dynamic linking (zlibwapi.lib) and that the zlibvc project remains unmodified (assuming you correctly followed the tutorial from the link above) and do not define it if you removed ZLIB_WINAPI from the zlibstat project (like the tutorial tell us to)!

One helpful macro I used on my own project is as follows:

// Since we used dynamic linking for debug, we have to define the ZLIB_WINAPI
#if defined(_WIN32) && defined(_DEBUG)
    #define ZLIB_WINAPI
#endif
#include <zlib.h>

Things got really confusing and I really hope I was clear enough.

---

Related Topics