Problems with SOCI - c++

I'm trying to use the SOCI library for easy MySQL access but I'm stuck at installing the library.
What I've done so far is :
Made the project and compiled it with CMake
Linked my project to the lib/release directoy that's created after compilation.
Linked my project to the MySQL C Connector lib directory
and here are my additional include directories :
http://puu.sh/6qGNP.png
But somehow, when I compile the example program, I get a bunch of linker errors like these :
1>main.obj : error LNK2019: unresolved external symbol "public: virtual __thiscall soci::details::standard_into_type::~standard_into_type(void)" (??1standard_into_type#details#soci##UAE#XZ) referenced in function "public: virtual __thiscall soci::details::into_type::~into_type(void)" (??1?$into_type#H#details#soci##UAE#XZ)
1>main.obj : error LNK2001: unresolved external symbol "protected: virtual void __thiscall soci::details::standard_into_type::post_fetch(bool,bool)" (?post_fetch#standard_into_type#details#soci##MAEX_N0#Z)
Where did I mess up?

From the documentation:
Required Client Libraries
The SOCI MySQL backend requires MySQL's libmysqlclient client library.
Note that the SOCI library itself depends also on libdl, so the minimum set of libraries needed to compile a basic client program is:
-lsoci_core -lsoci_mysql -ldl -lmysqlclient
This has always worked for me. If you want to link them from the build location a -L switch with the path to the libraries will need to be passed to the compiler.

Related

How to build wxWidgets with Visual C++

I followed along with the instructions for building wxWidgets on windows. I opened up a VS2019 command prompt and ran this build command and it finished successfully.
nmake /f makefile.vc BUILD=debug TARGET_CPU=X64
Trying to use this in another project hasn't been going as good. I copied the minimal sample program and while it compiles, I get ~330 link errors (LNK2019+LNK2001).
These are my project settings:
Include paths: {wxdir}\include, {wxdir}\lib\vc_x64_lib\mswd
Lib paths: {wxdir}\lib\vc_x64_lib
Linker inputs (these are all the libs that were created): wxbase31ud.lib;wxbase31ud_net.lib;wxbase31ud_xml.lib;wxexpatd.lib;wxjpegd.lib;wxmsw31ud_adv.lib;wxmsw31ud_aui.lib;wxmsw31ud_core.lib;wxmsw31ud_gl.lib;wxmsw31ud_html.lib;wxmsw31ud_media.lib;wxmsw31ud_propgrid.lib;wxmsw31ud_qa.lib;wxmsw31ud_ribbon.lib;wxmsw31ud_richtext.lib;wxmsw31ud_stc.lib;wxmsw31ud_webview.lib;wxmsw31ud_xrc.lib;wxpngd.lib;wxregexud.lib;wxscintillad.lib;wxtiffd.lib;wxzlibd.lib
Global defines: WIN32;_DEBUG;_CRT_SECURE_NO_DEPRECATE=1;_CRT_NON_CONFORMING_SWPRINTFS=1;_SCL_SECURE_NO_WARNINGS=1;__WXMSW__;_UNICODE;_WINDOWS;NOPCH;
Changing the linker inputs has no effect on the errors at all, even when I remove everything. So I think I must be missing some crucial part of the set up process.
Here are the first 5 of the link errors in case it helps:
error LNK2001: unresolved external symbol "protected: static struct wxEventTable const wxFrame::sm_eventTable" (?sm_eventTable#wxFrame##1UwxEventTable##B)
error LNK2001: unresolved external symbol "int const wxEVT_NULL" (?wxEVT_NULL##3HB)
error LNK2001: unresolved external symbol "class wxEventTypeTag<class wxCommandEvent> const wxEVT_MENU" (?wxEVT_MENU##3V?$wxEventTypeTag#VwxCommandEvent####B)
error LNK2001: unresolved external symbol "protected: static class wxAppConsole * (__cdecl* wxAppConsoleBase::ms_appInitFn)(void)" (?ms_appInitFn#wxAppConsoleBase##1P6APAVwxAppConsole##XZA)
error LNK2001: unresolved external symbol "void (__cdecl* wxTheAssertHandler)(class wxString const &,int,class wxString const &,class wxString const &,class wxString const &)" (?wxTheAssertHandler##3P6AXABVwxString##H000#ZA)
Edit: After inspecting some .lib files with dumpbin.exe I found out they are 32-bit. But I specified "TARGET_CPU=X64" in my nmake command. And the output lib folder was called "vc_x64_lib". Is there some other way of specifying x64 that I'm not aware of?
Edit 2: After using the 'x64 Native Tools' command prompt instead, nmake generated 64-bit libs. This had no effect on the link errors...
The simples solution is to install wxWidgets via vcpkg. I have done it today. You can then create a C++ - project (subsystem: Windows and not Console).

C++ - Unable to link in libyaml using Visual Studio 2019/CMake

Attempting to link in libyaml (0.2.5) using Visual Studio 2019 Enterprise and CMake, as I have a cross-platform (Linux/Windows) project that uses this library. According to the documentation, this library should work in Windows 10. It links in just fine on Linux (64-bit machine).
I'm compiling it as a static lib, and it has no issue generating the .lib file. I've copied it to the appropriate location that I'm linking in from my CMakelists.txt, as well as the header.
When I link it in from my project on Windows:
ts.lib(yamlparser.cxx.obj) : error LNK2019: unresolved external symbol __imp_yaml_parser_initialize referenced in function "public: bool __cdecl YAMLParser::parse_cfg(void)" (?parse_cfg#YAMLParser##QEAA_NXZ)
ts.lib(yamlparser.cxx.obj) : error LNK2019: unresolved external symbol __imp_yaml_parser_set_input_file referenced in function "public: bool __cdecl YAMLParser::parse_cfg(void)" (?parse_cfg#YAMLParser##QEAA_NXZ)
ts.lib(yamlparser.cxx.obj) : error LNK2019: unresolved external symbol __imp_yaml_parser_scan referenced in function "public: bool __cdecl YAMLParser::parse_cfg(void)" (?parse_cfg#YAMLParser##QEAA_NXZ)
This is what I'm doing on the CMake side - the very same thing I'm doing to link in my GoogleTest libraries on both Linux and Windows:
if (UNIX)
...
...
else()
set (MY_LIB_DIR "C:/mylib/lib")
set (MY_INCLUDE "C:/mylib/include")
set (YAML_LIB "${MY_LIB_DIR}/yaml.lib")
set (VCPKG_LIBRARY_LINKAGE static)
endif()
include_directories(${MY_INCLUDE})
add_library(ts
...
...
)
add_executable(myexec main.cxx)
target_link_libraries(myexec ts ${YAML_LIB})
VS isn't giving me many clues here except that there's a linkage problem that I can't quite figure out.
Any advice on how I can debug this or what the problem may be?
The __imp was the clue that my code was trying to include the library dynamically... Opening up yaml.h, I noticed that it tries to export from DLL unless YAML_DECLARE_STATIC is defined. Defined this in CMake and my issue is resolved.

How to build a static Clucene library to avoid any linker errors

I work with Windovs and I need to build a static CLucene library. I downloaded the latest source code and build them into Visual Studio 2010 Project through CMake-gui 3.4.3. When building I used a flag BUILD_STATIC_LIBRARIES = true. I successfully built two libraries: clucene-core-statics and clucene-shared-static. However, when I run the test project cl-test-static occurs a lot of linker errors. The same thing happens when I add these libraries in another test project.
Error Example:
Error 1 error LNK2019: unresolved external symbol
"__declspec(dllimport) public: static wchar_t * __cdecl
lucene::queryParser::QueryParser::escape(wchar_t const *)"
(__imp_?escape#QueryParser#queryParser#lucene##SAPA_WPB_W#Z)
referenced in function "public: void __thiscall Main::Start(void)"
(?Start#Main##QAEXXZ) c:\Users\user\documents\visual studio
2010\Projects\TestClucene\TestClucene\Main.obj TestClucene
Does anyone have any experience in building static CLucene libraries?

unresolved external symbol _gluLookAt#72 referenced in function

I'm making a program using the glu library but when i compile i got this error:
1>opengl_3.obj : error LNK2019: unresolved external symbol _gluLookAt#72 referenced in function "public: void __thiscall OpenGLContext::setupScene(void)" (?setupScene#OpenGLContext##QAEXXZ)
I included GL/glu.h and checked if the lib and dll were present. (they are by default)
I'm using visual studio 2012.
Any idea where this error is coming from?
You are not linking to glu. Add glu to the libraries against which your program should be linked. A more detailed description can be found here.

Using a DLL that links to a static lib

I'm trying to build a solution in Visual C++ where I have a front-end project that references a DLL project that I created. In the DLL project I link to a static library (that I have not written) that has static objects and definitions. Everything builds fine but I have linking problems.
I have a couple of questions. First, I should only get unresolved symbols for objects that I reference in the front-end that are not exported, right? I want the DLL to be the only interface to the static library and do not directly reference any part of it in the front-end, and yet I get a number of unresolved symbols from this library. There symbols seem to be #included and at least some not directly linked by the DLL project. I suspect it has to do with the static declarations in the static lib but how can I deal with these?
Some of the unresolved symbol errors:
2>AnalysisVis.obj : error LNK2001: unresolved external symbol "public: __thiscall SharkException::SharkException(char const *,int,char const *)" (??0SharkException##$$FQAE#PBDH0#Z)
2>AnalysisVis.obj : error LNK2001: unresolved external symbol "public: static class Bernoulli Rng::coinToss" (?coinToss#Rng##2VBernoulli##A)
2>AnalysisVis.obj : error LNK2001: unresolved external symbol "public: virtual bool __thiscall ChromosomeT<bool>::operator<(class Chromosome const &)const " (??M?$ChromosomeT#_N##$$FUBE_NABVChromosome###Z)
The exported symbols are mangled. If the static lib was compiled using a different compiler (or compiler version) than the one you are using, it is possible that the symbols your application is expecting to see were defined in the static lib using a different name mangling scheme. You can use the following command to get the name mangling used in the static lib and then compare it to the one in the error message:
>pushd <path_to_msvc_dir>\Microsoft Visual Studio X.0\VC\bin
>dumpbin /all [static_lib_path] > out.txt
>type out.txt | find /I "SharkException"
>type out.txt | find /I "coinToss"
>type out.txt | find /I "ChromosomeT"
BTW, does the DLL that uses the static lib compiles cleanly with the same compiler your application/solution does?