I have the following linker error in one project of a Visual Studio 2013 solution:
error LNK2019: unresolved external symbol "__declspec(dllimport) public: static class std::locale::_Locimp * __cdecl std::locale::_Getgloballocale(void)" (__imp_?_Getgloballocale#locale#std##SAPEAV_Locimp#12#XZ) referenced in function "class std::ctype<char> const & __cdecl std::use_facet<class std::ctype<char> >(class std::locale const &)" (??$use_facet#V?$ctype#D#std###std##YAAEBV?$ctype#D#0#AEBVlocale#0##Z)
In all projects I linked the run-time library dynamically (/MD).
I considered the hints in the following posts:
C++ linker unresolved external symbols
What libraries do I
need to link my mixed-mode application to?
Boost -
Unresolved external symbols when compiling linking with /MT instead
of /MD
Link error 2001:unresolved external symbol
Linker errors between multiple projects in Visual C++
but was not able to solve this issue.
Actually, I am not even aware of where in the project _Getgloballocale is used. Maybe it would also help to know the lib in which _Getgloballocale is located.
The projects use the following libraries:
cURL
Protobuf
libboost_thread-vc120-mt-1_56.lib
libboost_system-vc120-mt-1_56.lib
libboost_python-vc120-mt-1_56.lib
libboost_filesystem-vc120-mt-1_56.lib
In all projects I linked the run-time library dynamically (/MD).
As others noted, verifying this might be less obvious than appears. For one, some of your libraries might drag in external dependencies that do rely on a mis-matching runtime.
Suggest you link with /VERBOSE on (in your EXE project, properties / linker / general / show progress), and search the output dump for MSVCR. You might catch a different version (msvcr100.lib) or a different configuration (msvcr120d.lib). Also try to search for LIBCMT - that is the library for static linking of the runtime. These typically appear as part of a /DEFAULTLIB linker directive, and you should be able to understand from the dump in which library context this directive is present.
You can also post here the verbose output (or the relevant snippets), and we can try to help interpret it.
Related
I have a C++ Visual Studio DLL project that has a link error:
MSVCRTD.lib(tncleanup.obj) : error LNK2019: unresolved external symbol __imp__InitializeSListHead#4 referenced in function "void __cdecl __scrt_initialize_type_info(void)" (?__scrt_initialize_type_info##YAXXZ)
I set the Project Properties, Linker, General, Show Progress to "For Libraries Searched" to verify the correct version of MSVCRTD.lib is being referenced.
Look up the unresolved external symbol: InitializeSListHead to find what library it is defined in:
https://msdn.microsoft.com/en-us/library/windows/desktop/ms683482(v=vs.85).aspx
Kernel32.lib
In Visual Studio, set the Project Properties, Linker, General, Show Progress to “For Libraries Searched (/VERBOSE:Lib)"
Start a build and examine the output to see the "Searching libraries" referencing "Kernel32.lib".
In my case I found another Kernel32.lib was being referenced incorrectly.
I downloaded and compiled GraphicsMagick, 1.3.23, Q16, x64, StaticMT version. I had to convert the Visual Studio 7 solution generated by GraphicsMagick's build utility to Visual Studio 2015 format. I linked my project to CORE_DB_magick_.lib and CORE_DB_Magick++_.lib.
When the linker ran, it produced unresolved external symbols when linking InitializeMagick() and DestroyMagick()
1>wtd.lib(WebController.obj) : error LNK2019: unresolved external symbol __imp_DestroyMagick referenced in function "public: __cdecl Wt::WebController::~WebController(void)" (??1WebController#Wt##QEAA#XZ)
1>wtd.lib(WebController.obj) : error LNK2019: unresolved external symbol __imp_InitializeMagick referenced in function "public: __cdecl Wt::WebController::WebController(class Wt::WServer &,class std::basic_string,class std::allocator > const &,bool)" (??0WebController#Wt##QEAA#AEAVWServer#1#AEBV?$basic_string#DU?$char_traits#D#std##V?$allocator#D#2##std##_N#Z)
I can't understand why the symbols are not being linked. Any ideas?
Apparently, GraphicsMagick Static versions do not link properly.
What is your project type? I had a similar problem when trying to link the GraphicsMagick libraries to a DLL.
The clue here is that __imp is the function decoration for DLL imports, so you're trying to link with DLL functions.
The problem is that the header magick/common.h, when linked to a DLL project, reads the current configuration of the Visual Studio pre-processor environment to determine which mode the library is in, which is obviously wrong if you're trying to link static libraries into your DLL, for example. In this case, it defines MagickExport to __declspec(dllimport).
AFAIK this is a bug in the library. For proper static build support, magick/common.h needs to do something like read information from the magick/magick_config.h to determine what mode the library was actually built in and define MagickExport appropriately.
Since your library is statically linked, you can fix this by commenting out everything in the define:
#if defined(MSWINDOWS) && !defined(__CYGWIN__)
and replacing it with:
#define MagickExport
#define ModuleExport
#define MagickGlobal
I'm trying to use an external DLL (provided by AutoItX) with Visual C++ 2010. AutoItX provides a DLL, but for some reason not a LIB, so I generated one with Visual Studio.
The problem is that the linker seems to have trouble linking against the library. I added AutoItX3.lib as an additional dependency under Properties->Linker -> Inputs, and added the directory to Properties -> Linker -> General -> Additional Library Directories. No matter what I do, I still get these errors:
1>main.obj : error LNK2019: unresolved external symbol _AU3_Send#8 referenced in function _WinMain#16
1>main.obj : error LNK2019: unresolved external symbol _AU3_WinWaitActive#12 referenced in function _WinMain#16
1>main.obj : error LNK2019: unresolved external symbol _AU3_Run#12 referenced in function _WinMain#16
1>main.obj : error LNK2019: unresolved external symbol _AU3_Sleep#4 referenced in function _WinMain#16
AU3_Send, AU3_WinWaitActive, AU3_Run, and AU3_Sleep are functions called by the program, main.cpp. I'm really out of ideas, because these functions clearly exist in the DLL. Any help would be appreciated.
It is very common to provide only DLLs as a mean of interfaces. Many software providers do that. Doing this has following impacts (consequences):
the client applications can only dynamically link to the library provided (hence the name Dynamic-Link Library). The binding between the provider (the library) and the consumer (the App or any other Library) is made dynamically.
the client must use LoadLibray and GetProcAddress in order to bind the library and retrieve the Symbols (functions) desired
the interface (contract) between the Library and the consumer should be documented via a Header file - see AutoIt3.h for example - (or any other documentation like a help file, ..)
No LIB is provided (since it is not needed), since the Linking takes place at runtime, not at compiler/linker time
To resolve your problem you just need to remove the static dependency (the LIB) you put in the Visual Studio configuration and set the dependency at runtime using LoadLibrary and GetProcAddress
Link errors like this sometimes occur when compiling C++ using Microsoft Visual C++ 6.0:
error LNK2001: unresolved external symbol __imp__close
error LNK2001: unresolved external symbol __imp__read
error LNK2001: unresolved external symbol __imp__lseek
error LNK2001: unresolved external symbol __imp__open
My fix, which I found after searching fruitlessly using Google for a long time, is this:
Do NOT disable language extensions. In the Project Settings dialog, in the C/C++ tab, make sure that the 'Disable language extensions' checkbox is not checked.
The functions close, read, lseek, open, etc., are not standard parts of the C library and the declarations are skipped by conditional compilation using #if !__STDC__ in <io.h>. This happens if you disable language extensions.
The answer is that the __imp prefix refers to function stubs in the OBJ library for the DLL version of the CRT. This means your linker options are incompatible with your compiler options (linker set to static CRT or no CRT and compiler set to dynamic CRT).
In your case rather than the CRT itself it is another library, but the same idea.
I'm building an application against some legacy, third party libraries, and having problems with the linking stage. I'm trying to compile with Visual Studio 9. My compile command is:
cl -DNT40 -DPOMDLL -DCRTAPI1=_cdecl
-DCRTAPI2=cdecl -D_WIN32 -DWIN32 -DWIN32_LEAN_AND_MEAN -DWNT -DBYPASS_FLEX -D_INTEL=1 -DIPLIB=none -I. -I"D:\src\include" -I"C:\Program Files\Microsoft Visual Studio
9.0\VC\include" -c -nologo -EHsc -W1 -Ox -Oy- -MD mymain.c
The code compiles cleanly. The link command is:
link -debug -nologo -machine:IX86
-verbose:lib -subsystem:console mymain.obj wsock32.lib advapi32.lib
msvcrt.lib oldnames.lib kernel32.lib
winmm.lib [snip large list of
dependencies] D:\src\lib\app_main.obj
-out:mymain.exe
The errors that I'm getting are:
app_main.obj : error LNK2019:
unresolved external symbol
"_\_declspec(dllimport) public: void
__thiscall std::locale::facet::_Register(void)"
(__imp_?_Register#facet#locale#std##QAEXXZ)
referenced in function "class
std::ctype<char> const & __cdecl
std::use_facet<class std::ctype<char>
(class std::locale const &)" (??$use_facet#V?$ctype#D#std###std##YAABV?$ctype#D#0#ABVlocale#0##Z)
app_main.obj : error LNK2019:
unresolved external symbol
"__declspec(dllimport) public: static
unsigned int __cdecl
std::ctype<char>::_Getcat(class
std::locale::facet const * *)"
(__imp_?_Getcat#?$ctype#D#std##SAIPAPBVfacet#locale#2##Z)
referenced in function "class
std::ctype<char> const & __cdecl
std::use_facet<class std::ctype<char>
(class std::locale const &)" (??$use_facet#V?$ctype#D#std###std##YAABV?$ctype#D#0#ABVlocale#0##Z)
app_main.obj : error LNK2019:
unresolved external symbol
"__declspec(dllimport) public: static
unsigned int __cdecl
std::ctype<unsigned
short>::_Getcat(class
std::locale::facet const * *)"
(__imp_?_Getcat#?$ctype#G#std##SAIPAPBVfacet#locale#2##Z)
referenced in function "class
std::ctype<unsigned short> const &
__cdecl std::use_facet<class std::ctype<unsigned short> >(class
std::locale const &)"
(??$use_facet#V?$ctype#G#std###std##YAABV?$ctype#G#0#ABVlocale#0##Z)
mymain.exe : fatal error LNK1120: 3
unresolved externals
Notice that these errors are coming from the legacy code, not my code - app_main.obj is part of the legacy code, while mymain.c is my source. I've done some searching around, and what that I've read says that this type of error is caused by a mismatch with the -MD switch between my code and the library that I'm linking to. Since I'm dealing with legacy code, a solution has to come from my environment. It's been a long time since I've done C++ work, and even longer since I've used Visual Studio, so I'm hoping that this is just some ignorance on my part. Any ideas on how to get these resolved?
These are standard library references. Make sure that all libraries (including the standard library) are using the same linkage. E.g. you can't link statically while linking the standard lib dynamically. The same goes for the threading model used. Take special care that you and the 3rd party library use the same linkage options.
This can be a real pain in the *ss.
Check this on MSDN:
/MD Causes your application to use the multithread- and DLL-specific version of the run-time library.
/MT Causes your application to use the multithread, static version of the run-time library.
Note: "... so that the linker will use LIBCMT.lib to resolve external symbols"
So you'll need a different set of libraries.
How I went about finding out which libraries to link:
Find a configuration that does link, and add /verbose option.
Pipe the output to a text file.
Try the configuration that doesn't link.
Look in the verbose output from step 2 for the symbols that are unresolved ("_declspec(dllimport) public: void thiscall std::locale::facet::Register(void)" in your case) and find the used libraries.
Add those libraries to the list of libraries you're linking to.
Old skool but it worked for me.
Jan
If you still wish to get the project to compile using VS2008 (or in the future) I can suggest using a binary editor to view the object file in question mainapp.obj.
Here is an example from a small project of mine.
The zdbException.obj contains the following excerpt
DEFAULTLIB:"libc
pmtd" /DEFAULTLI
B:"uuid.lib" /DE
FAULTLIB:"uuid.l
ib" /include:?id
#?$num_put#DV?$o
streambuf_iterat
or#DU?$char_trai
ts#D#std###std##
#std##2V0locale#
2#A /include:?id
#?$numpunct#D#st
d##2V0locale#2#A
/DEFAULTLIB:"LI
BCMTD" /DEFAULTL
IB:"OLDNAMES" /E
DITANDCONTINUE
Note the entry /DEFAULTLIB:"LIBCMTD". This indicates the object file was compiled with the static c run-time multi-threaded debug.
There is also the possibility that the functions referenced in the obj are deprecated in the standard run-time lib shipped with VS2008.
After trying to get this stuff to compile under VS 2008, I tried earlier versions of VS - 2005 worked with warnings, and 2003 just worked. I double checked the linkages and couldn't find any problems, so either I just couldn't find it, or that wasn't the problem.
So to reiterate, downgrading to VS 2003 fixed it.