LNK2019: Undefined external symbol _Getgloballocale, Visual Studio 2013

Question

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

Answer 1

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.