I am trying to build the cpp-netlib library from Visual Studio 2010 but get the following linker error:
error LNK2019: unresolved external symbol "bool __cdecl
boost::network::uri::detail::parse_uri_impl(class
boost::iterator_range,class std::allocator > > &,struct
boost::network::uri::detail::uri_parts_default_base &,struct
boost::network::tags::default_string)"
(?parse_uri_impl#detail#uri#network#boost##YA_NAAV?$iterator_range#V?$_String_const_iterator#DU?$char_traits#D#std##V?$allocator#D#2##std###4#AAUuri_parts_default_base#1234#Udefault_string#tags#34##Z)
referenced in function "bool __cdecl
boost::network::uri::detail::parse_uri,class
std::allocator >,struct
boost::network::http::tags::http_default_8bit_tcp_resolve>(class
std::basic_string,class
std::allocator > &,struct
boost::network::uri::detail::uri_parts &)"
(??$parse_uri#V?$basic_string#DU?$char_traits#D#std##V?$allocator#D#2##std##Uhttp_default_8bit_tcp_resolve#tags#http#network#boost###detail#uri#network#boost##YA_NAAV?$basic_string#DU?$char_traits#D#std##V?$allocator#D#2##std##AAU?$uri_parts#Uhttp_default_8bit_tcp_resolve#tags#http#network#boost###0123##Z)
A little bit of digging turned up that this could be related to the version of Boost I'm using (1.46.1) but I have tried compiling against both 1.47.0 and 1.45.0 and get the same error.
What is required to get this library to compile?
After a lot of searching I found this post and this one from the creator of the library, mentioning:
An option to turn off the required external library to be linked with a macro (BOOST_NETWORK_NO_LIB). With this macro defined before
any cpp-netlib headers are included (or on the command line) the
functions that were made extern or just free functions at namespace
level are marked 'inline' and have their definitions pulled in
accordingly in each translation unit. This addresses Jeff Garland's
and others' concern of the need for an external library when using
cpp-netlib when it's always been header-only until 0.9. I'm still
wrestling with the thought of making the header-only behavior a
default, but I'm not married to the "external library as default"
decision either.
I am able to compile if I add that macro definition before my cpp-netlib headers like so:
#define BOOST_NETWORK_NO_LIB
#include <boost/network/protocol/http/client.hpp>
In the second post I found there is also mention of "You need to build/link against the uri library" which sounds like it might be a better solution.
Unfortunately my knowledge of c++ and boost isn't the best so I just went with what worked.
Any better approaches are welcome, though all I really wanted to do was compile the library so I can evaluate it for real use, so I'm happy right now.
Related
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 &)"......
How can I get around missing boost::throw_exception while building PCL?
I've built PCL on Windows (MSVC 2013) a few times in the past, but I've never see this error. It's been blocking me all today and yesterday:
LNK2019: unresolved external symbol "void __cdecl boost::throw_exception(class std::exception const &)" (?throw_exception#boost##YAXAEBVexception#std###Z) referenced in function "public: __cdecl boost::detail::shared_count::shared_count<struct pcl::io::ply::ply_parser::list_property<unsigned char,signed char> >(struct pcl::io::ply::ply_parser::list_property<unsigned char,signed char> *)" (??$?0U?$list_property#EC#ply_parser#ply#io#pcl###shared_count#detail#boost##QEAA#PEAU?$list_property#EC#ply_parser#ply#io#pcl###Z) [C:\Users\mrussell\.conan\data\pcl\1.7.2\ntc\stable\build\d63ff451cbfa147e3b952f2f3790530e1116d93c\io\pcl_io_ply.vcxproj]
It appears that BOOST_NO_EXCEPTIONS is set in boost\config\compiler\visualc.hpp, which prevents boost/throw_exception.hpp from defining it.
I've tried to set TPN_WIN32 to /EHsc (see this answer) both through CMake and via the project properties in Visual Studio to no avail, and even tried sneaking a definition into a high level PCL include (see this answer), nothing worked.
My CMake generator is Visual Studio 12 2013 Win64 and my definitions are:
-DBOOST_ROOT:PATH=%CONAN_BOOST%
-DCMAKE_INSTALL_PREFIX=%CONAN_PCL%
-DEIGEN3_DIR:PATH=%CONAN_EIGEN%\share\eigen3\cmake
-DEIGEN_INCLUDE_DIR:PATH=%CONAN_EIGEN%\include\eigen3
-DFLANN_INCLUDE_DIR:PATH=%CONAN_FLANN%\include
-DFLANN_LIBRARY:FILEPATH=%CONAN_FLANN%\lib\libflann_cpp.so
-DQHULL_INCLUDE_DIR:PATH=%CONAN_QHULL%\include
-DQHULL_LIBRARY:FILEPATH=%CONAN_QHULL%\lib\libqhull.so
-DGTEST_ROOT:PATH=%CONAN_GTEST%
-DBUILD_surface_on_nurbs:BOOL=ON
I've tried:
Removing Qt & VTK
With Boost 1.60, 1.66, and 1.59
Linking against a shared and static versions of boost. (PCL does not seem to like shared boost on Windows...)
Attempting to build shared and static versions of PCL
I feel like I'm chasing the wrong thing, or am missing something. Maybe I'm missing a _CPPUNWIND define for exceptions? I'm really just stuck.
TPN_WIN32 is a user defined variable on that post you reference. You need to append /EHsc to your CMAKE_CXX_FLAGS to pass it to the compiler.
Unrelated but really suspicious -DFLANN_LIBRARY:FILEPATH=%CONAN_FLANN%\lib\libflann_cpp.so is a unix dynamic library. You can't link it on windows with MSVC.
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 have 2 projects in c++ (MFC)
One is a library project which im using in the second one (an executable one).
They work together great, until I call a function from the regular project that takes a CString as argument. I get a linker error like this
error LNK2019: unresolved external symbol "public: void __thiscall
CTextDisplay::SetText1(class ATL::CStringT<wchar_t,class StrTraitMFC_DLL<wchar_t,
class ATL::ChTraitsCRT<wchar_t> > >)" (?SetText1#CTextDisplay##QAEXV?$CStringT#_WV?
$StrTraitMFC_DLL#_WV?$ChTraitsCRT#_W#ATL#####ATL###Z) referenced in function
"public: void __thiscall CManualPane::SetBeadCountFor(int,double)"
(?SetBeadCountFor#CManualPane##QAEXHN#Z) C:\source\IQ-Project\IQ\ManualPane.obj IQ
The executable project has its character set to UNICODE but the Library has it set to Multy-Byte chatacter set. I really can't change them without getting ridiculous amounts of errors.
Any suggestions?
Edit: The reason we have different settings in these two projects is because the Executable project is basically an external project that my group didn't build or create. We just had to bring it in and use it. The library project is something we've all been working on for a couple years.
When you include the headers of the library project in the executable, there is likely a typedef which is used in the declaration of the function. Since the executable uses UNICODE, the declaration is now in UNICODE. However, the library implementation is still in MultiByte and so the definition doesn't match the declaration leading to the linker error.
Look into how these typedefs are being setup, and you might be able to do some special #define, #undef around the included header.
In the end it proved to be a better idea to avoid having unicode and multybyte projects in the same solution so I moved it all to unicode and went from there
I am using a library of code from a tutorial for providing functionality for passing function points of non-static member functions to a function that expects a static function pointer, probably helps to know what I am suing, so here is the link http://www.codeproject.com/KB/cpp/thunk32.aspx This code uses the Boost library, which I have downloaded and set-up more or less everything from.
In the Thunk library, one of the header files has a section that reads
#define BOOST_PP_ITERATION_PARAMS_1 (3,(0,THUNK32_MAX_ARGS,"Thunk32_template.h"))
??=include BOOST_PP_ITERATE()
#undef BOOST_PP_ITERATION_PARAMS_1
but this gives me epic amounts of errors, which I can solve by changing it to
#define BOOST_PP_ITERATION_PARAMS_1 (3,(0,THUNK32_MAX_ARGS,"Thunk32_template.h"))
#include BOOST_PP_ITERATE()
#undef BOOST_PP_ITERATION_PARAMS_1
This code that is downloaded is included in my solution as a second project, which is able to compile and build happily. But my project that is using this code has issues linking, to save people asking, I get these error messages
1>WebCamera.obj : error LNK2019: unresolved external symbol "protected: __thiscall indev::Thunk32Base::Thunk32Base(void)" (??0Thunk32Base#indev##IAE#XZ) referenced in function "public: __thiscall indev::Thunk32<class WebCamera,void __cdecl(struct HWND__ *,struct videohdr_tag *)>::Thunk32<class WebCamera,void __cdecl(struct HWND__ *,struct videohdr_tag *)>(void)" (??0?$Thunk32#VWebCamera##$$A6AXPAUHWND__##PAUvideohdr_tag###Z#indev##QAE#XZ)
1>WebCamera.obj : error LNK2019: unresolved external symbol "protected: __thiscall indev::Thunk32Base::~Thunk32Base(void)" (??1Thunk32Base#indev##IAE#XZ) referenced in function "public: __thiscall indev::Thunk32<class WebCamera,void __cdecl(struct HWND__ *,struct videohdr_tag *)>::~Thunk32<class WebCamera,void __cdecl(struct HWND__ *,struct videohdr_tag *)>(void)" (??1?$Thunk32#VWebCamera##$$A6AXPAUHWND__##PAUvideohdr_tag###Z#indev##QAE#XZ)
1>WebCamera.obj : error LNK2019: unresolved external symbol _capCreateCaptureWindowA#32 referenced in function "public: bool __thiscall WebCamera::Init(struct HWND__ *)" (?Init#WebCamera##QAE_NPAUHWND__###Z)
I think this is trying to say that the constructor and destructor are not declared and that my WebCamera.Init()is messed up as well. I have made sure that the library that the Thunk32 project exports is included in my other project, but still I get these errors.
I would like to know if I have made the correct assumption that ??=include should have been changed to #include and if I have, what have I done wrong or failed to do that results in these linker errors. Or if you can provide me with a different way of being able to pass a function pointer to a non-static member function that would be awesome.
Thanks
??= is a "trigraph" sequence for the # character. according to the standard, trigraphs are supposed to be handled as one of the first steps in processing (in phase 1 - before the preprocessor handles directives),so:
??=include "whatever"
Should be equivalent to:
#include "whatever"
so you should be able to use that form (I wonder why the trigraph was put there in the first place - some sort of evil joke perhaps?)
However, trigraphs cause problems and confusion (probably more than they help), so compilers seem to be moving towards warning about them and/or defaulting to not handling them. The compiler in VS 2010 has trigraph processing turned off by default - you have to use the /Zc:trigraphs option to turn it on.
See Purpose of Trigraph sequences in C++? for more details.
Ah, Einar, good man. Doing flash and Sharepoint stuff these days, ouch. Norwegian, might explain the trigraphs.
Anyhoo, nothing complicated, you just forgot to tell the linker to look at some libraries. Right-click your project, Project Dependencies, tick the Thunk project. That makes sure that Thunk32.lib gets looked at and resolves the ctor and dtor.
Right-click again, Properties, Linker, Additional dependencies, add "winmm.lib". That resolves the capCreateCaptureWindow symbol.
Do you have a constructor and a destructor declared in the indev::Thunk32Base class that you forgot to define in its cpp file?
Ok, so I have managed to solve this now.
Michael Burr nicley said that ??= is basically the same as typing # but in a way that people who dont have the hash symbol can type it, see Purpose of Trigraph sequences in C++?
Hans Passant then got the ball rolling for me buy letting me know that I had not fully linked in stuff. I needed to right click on my main project, select 'Project Dependencies' and select my other project that has the thunk32 code. I also needed to tell my main project to look at where the Thunk project is saving the lib, which turned out to be in a folder in my documents (explain that one!). I also needed to add the Thunk32d.lib (note the 'd' because I was/am in debug mode. Hans said that I needed winmm.lib but it turned out (when googling the function that was giving me the error that I needed Vfw32.lib instead.
Thanks guys! I hope that by giving the full answer like this it can help some one else who has a similar problem.