Linking error while trying to build Boost.Log example - c++

I have successfully built the Boost.Log library on Windows 7 for VS 2010. When I tried to run the simplest example, my program could not find the symbols for Boost.System and Boost.Filesystem, and I got the 'undefined external symbol' errors. I have coped with that issue by manually including libboost_filesystem-vc100-mt-gd-1_48.lib and libboost_system-vc100-mt-gd-1_48.lib in the project.
Nevertheless, now I have another problem: while trying to build the "basic_usage" example for Boost.Log I get the error
error LNK2019: unresolved external symbol "private: void __thiscall boost::log_mt_nt5::sinks::basic_text_file_backend<char>::construct(class boost::filesystem3::path const &,int,unsigned __int64,class boost::function0<bool> const &,bool)"
How can I solve this problem?

I have found the solution!
The reason was that I've built the Boost.Log with the Boost.Filesystem v2, while it was supposed to built with v3. I have rebuilt it correctly and now it works perfectly.

Related

E0145 member "boost::filesystem::path::separator" may not be initialized & LINK2019 error in VS2017 using vcpkg

I start using vcpkg in my msvc C++ project recently.
I built the boost 1.67 and referred it in my vs project. After I installed vcpkg, I added some lib and vcpkg seems installed another boost for me and link it to my project. Unfortunately, that boost does't work. I am now having tens of error in building project. Most of them are E0145 and LINK2019. I'm new in c++ programming. I want to know how I can use the boost I built instead of the one vcpkg installed for me.
eg. one of the error is because it changes my BOOST_NO_CXX11_CONSTEXPR and try to use constexpr while it's not supported on my pc. The error is:
E0145 member "boost::filesystem::path::separator" may not be initialized c:\Users\admin\Libraries\boost_1_67_0\boost_1_67_0\boost\filesystem\path.hpp 65
this is my own boost file but all refer is to c:\Users\xxx\vcpkg\vcpkg\installed\x86-windows\include\boost\config\detail\suffix.hpp
instead of
C:\Users\xxx\Libraries\boost_1_67_0\boost_1_67_0\include\boost-1_67\boost\config\detail\suffix.hpp
What can I do to correct this?
The file structure of vcpkg-boost is differ from the boost 1.67 I used before. If I replace the files with 1.67 ones, I'm afraid it will be reset when I upgrade the vcpkg and its libraries. Please give me some advice on this.
And I also got error like,
LNK2019 unresolved external symbol "__declspec(dllimport) void __cdecl boost::filesystem::path_traits::convert(char const *,char const *,class std::basic_string<wchar_t,struct std::char_traits<wchar_t>,class std::allocator<wchar_t> > &,class std::codecvt<wchar_t,char,struct _Mbstatet> const &)"......

Including Lua in VS2015 C++ Project

I would like to integrate Lua into my current C++ application I build with VisualStudio 2015 (x64 mode).
I grabbed a simple Lua wrapper from here, and the Lua binaries for windows x64 from here (the lua-5.1.5_Win32_dll14_lib.zip one).
Next, I added the include and library path to the project preferences. Works so far in the IDE. However, when I try to compile the code it throws 24 errors (like these first two):
1>LuaScript.obj : error LNK2019: unresolved external symbol "lua_close" referenced in function ""public: __cdecl LuaScript::~LuaScript(void)" (??1LuaScript##QEAA#XZ)".
1>LuaScript.obj : error LNK2019: unresolved external symbol "lua_gettop" referenced in function ""public: void __cdecl LuaScript::clean(void)" (?clean#LuaScript##QEAAXXZ)".
which tells me next to nothing. Seems that the linker is unable to find the library but the includes are working and the path to library is set, too. Any suggestions what I might have missed or should look into? Any hint would be appreciated!

Link errors with GraphicsMagick

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

SFML and VS2013 - WinMain/main linker error

I am trying to use SFML with Visual Studio 2013 using the tutorial on the SFML website and using their sample code (replacing main() with WinMain()) but I'm getting the linker error:
Error 1 error LNK2019: unresolved external symbol _main referenced in function _WinMain#16
I am referencing the libs:
sfml-graphics-d.lib
sfml-window-d.lib
sfml-main-d.lib
sfml-system-d.lib
and I am pointing correctly to the 'include' and 'lib' folders in my Project Properties.
I have tried using 'main()' with sfml-main-d.lib referenced and 'WinMain()' without it referenced and I still get the linker error.
Any suggestions?
Thank you for your time
Okay I seem to have solved it but don't know how. I'll do my best to explain to anyone else who is stuck:
I started a new project again with a fresh download of SFML 32-bit for VS2013.
I added sfml-main-d.lib and sfml-main.lib to my referenced libs (for debug and release respectively) and then use "int main()..." instead of "int __stdcall WinMain()" and it linked and compiled correctly.
I thought I had already tried this combination but I guess maybe not.
Thanks to anyone who took the time to read this question and to Elried for commenting.

Compile Tesseract for Visual Studio 2013

I'm trying to use the tesseract in visual studio 2013. I'm using "libtesseract302.lib" in the the linker -> Input (not "libtesseract302-static.lib") and everythings was OK, and it's compiled and run, but when I tried to use this code:
tesseract::ResultIterator* ri;
tesseract::ChoiceIterator ci(*ri);
I got five link errors like this:
Error 3 error LNK2028: unresolved token (0A000567)
"public: __thiscall tesseract::ChoiceIterator::ChoiceIterator
(class tesseract::LTRResultIterator const &)"
(??0ChoiceIterator#tesseract##$$FQAE#ABVLTRResultIterator#1##Z)
referenced in function "int __cdecl main(void)" (?main##$$HYAHXZ)
I think it's because I didn't use the static library, so I tried that, but I got many linking errors. I think that is due to the static library having been built before using vs2008 that I got from here.
Tesseract
So I'm trying now to compile the tesseract as static lib in vs2013. Will solve the issue, or should I try something else?