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.
Related
I am trying to build OpenCV according to these instructions. After generating with CMake I opened OpenCV.sln in the build folder, switched to Release mode and built ALL_BUILD successfully. But when I try to build the INSTALL option under CMake, I get errors like this:
Error LNK2001 unresolved external symbol "public: virtual struct QMetaObject const * __cdecl cvv::qtutil::Signal::metaObject(void)const "
Error LNK2019 unresolved external symbol "public: void __cdecl cvv::qtutil::ZoomableImage::updateConversionResult(class cv::Mat const &,enum cvv::qtutil::ImageConversionResult)const "
...
I am installing OpenCV 4.2 on Windows 10 with Visual Studio 19. How can I solve this problem?
Here is an image of the error messages in Visual Studio:
Turning my comments into an answer:
The GitHub issue described here references similar errors to those you have posted. While the suggested "solution" seems more like a work-around, it may help resolve the issue. First, try building without the cvv module (an interactive GUI component of OpenCV), by running CMake with the BUILD_opencv_cvv variable set to OFF:
cmake -DBUILD_opencv_cvv=OFF ...
You can also set the variable using the CMake GUI, by clicking the Add Entry button, and defining BUILD_opencv_cvv to OFF.
The GitHub issue further explains that if there are still undefined reference errors after making this change, you can also try setting BUILD_opencv_world to OFF as well.
cmake -DBUILD_opencv_cvv=OFF -DBUILD_opencv_world=OFF ...
This may help get things building successfully, but it should be noted that these disabled modules will be left out of your build.
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 &)"......
For a research project, I'm writing a C++ add-on to a scientific computing language. Unfortunately the library that allows users to do this is not kept very well up-to-date.
I started the project in XCode, where it built fine. Later I had to move to a PC, so I migrated the code to Visual Studio 2015. Since doing this, I haven't been able to build due to the following errors:
LNK2001 : unresolved external symbol _sprintf
LNK2019 : unresolved external symbol _sscanf referenced in function _GetDDouble
LNK2019 : unresolved external symbol _sprintf referenced in function _CheckRunningInMainThread
An attempted fix was to add the header #define _CRT_SECURE_NO_WARNINGS. However, this a) fixed no errors and b) added the warning C4005 : '_CRT_SECURE_NO_WARNINGS': macro redefinition. I assume the library already defined this macro, anticipating this problem. Regardless, it didn't solve the problem.
How should I proceed?
Add the following library to the linker input files:
legacy_stdio_definitions.lib
VS 2015 now uses inline definitions that call internal functions for many of the stdio.h functions. If an object file (or library member) depends on one of those functions, then the legacy_stdio_definitions.lib provides an externally linkable version of the function that can be linked to.
Your other option is to recompile the unit that depends on those functions with VS 2015 (this is probably the preferred option).
I got this error compiling cycling max plugins against version 5 max sdk (pure c api). The legacy library fix didn't work for me (it should have, and if anyone had any idea why it mightn't I'd be curious), but I defined _NO_CRT_STDIO_INLINE before stdio was loaded and that did do the trick.
I recently encountered this and was able to add User32.lib to Linker > Input > Additional Dependencies.
You could also include #pragma comment (lib, "User32.lib") in your code.
I read through the boost documentation using the '5.3.4 Invoke b2' and followed up with forum threads that explained details of linking the boost library to the header and linker directories, in the boost help '4.1 Build From the Visual Studio IDE', and found this cool boost related wiki that explained the bjam.exe controls.
placed #include <boost/thread/thread.hpp> in the main.cpp
And, I get this linker error, and the existing help threads have identified the problem is with x64:
Directory path and x32/x64
unrelated to Visual studio
unresolved
The error:
error LNK2019: unresolved external symbol "class boost::system::error_category const & __cdecl boost::system::generic_category(void)" (?generic_category#system#boost##YAAEBVerror_category#12#XZ) referenced in function "void __cdecl boost::system::`dynamic initializer for 'posix_category''(void)" (??__Eposix_category#system#boost##YAXXZ) main.obj
error LNK2019: unresolved external symbol "class boost::system::error_category const & __cdecl boost::system::system_category(void)" (?system_category#system#boost##YAAEBVerror_category#12#XZ) referenced in function "void __cdecl boost::system::`dynamic initializer for 'native_ecat''(void)" (??__Enative_ecat#system#boost##YAXXZ) main.obj
they are similar, something about 'posix_category' and something about 'native_ecat'
So, I tried to build the x64 boost library, and found conflicting instructions on where to put these:
did not say "Note for x64 users: Add the address-model=64 option to bjam (after the threading argument) in order to build static libs with the 64-bit compiler."
cant find the link but one said to place x64 lib in the vs2008 bin?
Also, I tried changing the vs2008 configuration back to x32 -> solutionExplorer/solution_properties/configuration_manager/active_solution_platform - Win32, closed and reopened visual studio - relinked the additional directories C/C++/general and Linker/general to Boost/root and Boost/stage/lib - and it compiled without error.
My best guess at the b2 commands is --toolset=msvc-9.0 address-model=64 --build-type=complete --stagedir=lib\x64 stage
Please give concise instructions for how to build and install x64 version of boost on VS2008. Also, what was the wiki talking about for release and debug - they are not in Boost invocation?
use c++ 11
It more or less includes all the features of boost I wanted to use, also compiles in g++ without figuring out how to build the boost library on my university server and then reference into a remote g++ build - pretty much solved everything with that
I'm getting these errors:
1>test.obj : error LNK2019: unresolved external symbol "__declspec(dllimport) public: void __thiscall std::basic_ofstream<char,struct std::char_traits<char> >::`vbase destructor'(void)" (__imp_??_D? $basic_ofstream#DU?$char_traits#D#std###std##QAEXXZ) referenced in function _main
1>test.obj : error LNK2019: unresolved external symbol "__declspec(dllimport) public: __thiscall std::basic_ofstream<char,struct std::char_traits<char> >::basic_ofstream<char,struct std::char_traits<char>>(void)" (__imp_??0?$basic_ofstream#DU?$char_traits#D#std###std##QAE#XZ) referenced in function _main
This test code works fine:
int main(int argc, char **argv)
{
std::ofstream game_record_output;
}
until I include a .h from an older project that was converted from VS 2003 .NET
Firstly I thought it could have some problem related with this:
http://msdn.microsoft.com/en-us/library/8h8eh904(v=vs.90).aspx
But then, I've already checked that just MSVCRT.LIB and MSVCPRT.LIB are being linked, so the old iostream is not being linked...
I'm not sure why this happen, I'm supposing that in include chain some wrong file is being included, but I've already search the include chain for the old iostream .h's files (i.e: (fstream.h, iomanip.h, ios.h, iostream.h, istream.h, ostream.h, streamb.h, and strstrea.h) )
So, is there anything else that I should check?
The project use MFC.
Change your Visual Studio project Properties setting in C/C++ -> Code Generation -> Runtime Library according to this:
Multi-threaded Debug DLL (/MDd) for Debug configuration
Multi-threaded DLL (/MD) for Release configuration
This page contains some causes for LNK2019: https://msdn.microsoft.com/en-us/library/799kze2z.aspx . Particularly, upgrade from VS 2003 could trigger this problem:
A build dependency is only defined as a project dependency in the
solution. In earlier versions of Visual Studio, this level of
dependency was sufficient. However, starting with Visual Studio 2010,
Visual Studio requires a project-to-project reference. If your project
does not have a project-to-project reference, you may receive this
linker error. Add a project-to-project reference to fix it.
or this
You mix code that uses native wchar_t with code that doesn't. C++
language conformance work that was done in Visual C++ 2005 made
wchar_t a native type by default. You must use the /Zc:wchar_t-
compiler option to generate code compatible with modules compiled by
using earlier versions of Visual C++. If not all modules have been
compiled by using the same /Zc:wchar_t settings, type references may
not resolve to compatible types. Verify that wchar_t types in all
modules are compatible, either by updating the types that are used, or
by using consistent /Zc:wchar_t settings when you compile.