Reputation: 8994
I'm having serious issues linking a library despite doing the same routine I've done with all other libraries. The library is libmupdf.lib (a pdf viewing library).
Anyways, I have compiled the .lib and added it as a "Additional Dependencies" in the linker, added the header includes as additional includes, and specified where VSC++ should look for the libraries. It doesn't complain about not finding libmupdf.lib as linking begins.
I then get the standard looking linker error:
error LNK2019: unresolved external symbol "int __cdecl fz_strlcat(char *,char const *,int)" (?fz_strlcat@@YAHPADPBDH@Z) referenced in function "void __cdecl winerror(struct pdfapp_s *,int)" (?winerror@@YAXPAUpdfapp_s@@H@Z)
However, if I do the below I see that fz_strlcat is indeed in libmupdf.lib but prepended with a _ .... is this normal?
C:\Program Files\Microsoft Visual Studio 10.0\VC>dumpbin /SYMBOLS "libmupdf.lib" | "grep.exe" fz_strlcat
033 00000000 SECTC notype () External | _fz_strlcat
060 00000000 UNDEF notype () External | _fz_strlcat
381 00000000 UNDEF notype () External | _fz_strlcat
Note: I tried changing the call to fz_strlcat to _fz_strlcat and made the change in the header, but still no linkage.
Any clues or help is appreciated at this point. Thanks!
Upvotes: 0
Views: 1178
Reputation: 75125
You seem to be missing the Fitz library. This is part of the MuPDF project but it builds as a separate LIB file.
Edit
I stand corrected: in looking at the vcproj files on MuPDF's GIT repository, it appears that libmupdf.lib builds as one big library, with all the Fitz stuff as well as even 3rd party libraries per-se.
Now... in looking in more detail at the error message, this looks like a C vs C++ linkage issue. Am I wrong in seeing that the fz_strlcat function is called from C++, whereby fitz.h has maybe not been included with the extern "C" {}
linkage?
What happen in such case is that C++ produces a mangled name for linkage (fz_strlcat@@YAHPADPBDH@Z
), one that includes codes for the full signature of the function (parameter types etc.).
By adding
extern "C" {
#include "fitz.h" // or whatever other include file which in turn includes fitz.h
}
around the includes that pertain to functions and variables in the libmupdf library, the LNK error should disappear.
Upvotes: 8