I am using VS2010 Express and just installed Boost v1_47. I have added the 'include' folder to 'additional include folders' option, and also the 'lib' folder to the 'additional libraries' option in VS.
Then, I included boost/regex.hpp in one of my files, but actually wrote no code using boost yet. However, when building the solution I get lots of error messages, coming in two flavours:
Redefiniton errors, such as:
1>D:\boost\boost_1_47\boost/detail/interlocked.hpp(83): error C2373: '_InterlockedCompareExchangePointer' : redefinition; different type modifiers
1> C:\Program Files\Microsoft SDKs\Windows\v7.1\include\winnt.h(2597) : see declaration of '_InterlockedCompareExchangePointer'
Invalid calling convention errors (lots of these), such as:
D:\boost\boost_1_47\boost/regex/v4/regex_traits_defaults.hpp(271): error C3641: 'boost::re_detail::global_lower' : invalid calling convention '__cdecl ' for function compiled with /clr:pure or /clr:safe
Note: I haven't explicitly included winnt.h in any of my source/header files, and have tried de-activating pre-compiled headers and removing the stdafx.h includes, but it didn't solve the problem.
What's going on?
Thanks in advance
You have to make sure that you compile your program with the same settings as boost.
It seems like you used the wrong project template (CLR something) to create your application project.
You could try to modify the properties of your existing project to make it compatible with boost, but the CLR ... projects have lots of incompatible property values set by default, so i think the easiest way would be to create a new project from scratch (and import your existing code).
You should use the "Empty Project" template and create a new project, and then add your existing source and header files to it, and add the boost include path again, and add any required boost .lib files to Project Properties > Linker > Input > Additional Dependencies (Most boost libraries work out of the box without adding anything to linker inputs because they are header only, so you might not need to add any .libs).
Boost is a C++ required, designed to be consumed by C++ code, not C++/CLI code, thus it can only be used with native C++ classes, and most boost headers will produce headers when included in a source file which contains C++/CLI code.
Related
I am building a DLL using visual studio, which involves installing the following libraries :
GLM
GLFW
GLEW
I linked those libraries to visual studio using the following method :
specifying Additional Include Directories in the project property page
specifying Additional Dependencies in the project property page
specifying Additional Library Directories in the project property page
Of course GLM is a header only Library, which means that I am only required to specify the Additional Include Directories for GLM. And my dll built perfectly fine.
But the real problem occurs when using the library in a test project. I linked my test project to my library using the method mentioned above, but when I tried to build the test project, it produces the following results :
Cannot open include file <GLFW/glfw3.h>
And the same goes for glew. It seems that these libraries are not found when the library is being used by another test project. How can I fix this? Any help would be highly appreciated.
Set the Additional Include Directories correctly for all projects. The compiler doesn't magically inherit settings from a project which happens to have it's output linked into another project. So you have to provide it the correct include path for any source file it sees. To spare yourself from having hardcoded paths to include directories you could use a property sheet common for both projects. Or you could tackle the problem in code and make use of the PIMPL idiom (eventually as simple as e.g. forward declaring some GL types and using a unique_ptr to them in public classes) so the headers of your project never expose any of the external include files.
I am trying to build Quantlib using Boost Libraries.
I followed the instructions here: and also on the Quantlib website.
I downloaded and unzipped boost_1_57_0 into C:\program files
I then used the Visual Studio 2013 x64 Native prompt to go to the boost directory and ran
bootstrap.bat
and then
b2 --toolset=msvc --build-type=complete architecture=x86 address-model=64 stage
Then I opened Quantlib_vc12.sln in Visual Studio 2013.
Picked "Release" and "x64", opened "Quantlib" in Property Manager and set the VC++ Directories.
In the include directories I added C:\Programm Files\boost_1_57_0
In the Library Directories I added C:\Program Files\boost_1_57_0\stage\lib
Then I went to the Solution Explorer and right clicked and chose build.
I got one LNK1104 error.
LNK1104: cannot open file 'libboost_unit_test_framework-vc120-mt-1_57.lib
Please see attached screenshot:
I have no idea how to fix this and I would really appreciate some help. I had successfully installed this at work using an admin account but was not able to access Quantlib using my user account. I have since deleted and attempted installations atleast 15 times but it's not working. I am worried that all these attempts at installing may have messed something else up, like some registry (I have no idea how that works but I only know to be afraid). Please help! Thanks.
UPDATE: Still get the same error after adding BOOST_AUTO_LINK_NOMANGLE define to project.
UPDATE2: I am getting these messages on the screen while running b2 to build boost. Is this an error I need to fix?
This is exactly what I warned you about in another related question/answer. What's happening here is that the boost headers you are including in this quantlib are (through macros) detecting that you're using MSVC, detecting the version, then automatically linking the required DLL files to build quantlib using #pragma comment(lib....). So even though under Project Settings -> C/C++ -> Linker there are no external DLL's or Lib's specified, they're still being linked by these pragma statements.
So when these macros are detecting your compiler and so on, they're dynamically building a string name of what they think the required libraries would be named on your system. Remember when you built boost, you specified the -layout option. This the naming layout of your boost libraries. Well by default, that layout is something like this:
LIB_LIBRARY_NAME_COMPILER_VERSION_SingleOrMultiThreaded_BOOST_VERSION.LIB
Which in practice looks like this:
libboost_unit_test_framework-vc120-mt-1_57.lib
This is boost "mangling" the name of your library to be as descriptive as possible about how the libraries were build so that, just by glancing at the file name, you know. What we do with -layout=system is tell the boost build system NOT to mangle the names, but to name them according to what option we gave to "layout". Since we chose layout=system, boost is going to name our libraries like this:
LIB_LIBRARY_NAME.LIB
Which in practice will produce:
libboost_unit_test_framework.lib
So when we start using boost after doing this (with MSVC only does this happen), these dynamically generated linker statements don't give a rip about or know about what -layout option you built boost with. They will attempt to link in required libraries using the fully mangled naming format, which is why you get the error:
cannot open file 'libboost_unit_test_framework-vc120-mt-1_57.lib
.. because you don't have a file named that! That's the mangled name! You have a file named libboost_unit_test_framework.lib. See the difference! So, you need to tell these stupid macros to stop mangling the library names when auto-linking required libraries. You do that by adding the following preprocessor definition to your Quantlib project:
BOOST_AUTO_LINK_NOMANGLE
You add that in Project Settings -> C/C++ -> Preprocessor -> Preprocessor definitions.
If you'd rather avoid this headache and don't care about the long and (imo ugly) mangling that boost does to library names, you can build boost omitting the -layout option and it will default to this mangled naming convention, where you shouldn't get stuck on this error at all anymore. I personally put out the effort to keep nice short/clean library names but it's all about preference.
Edit
Since you have the same error after fixing the NO_MANGLE problem, then the only possible reason that you're getting this particular link error is that you do not have whatever file the linker is complaining about missing stored in any of the directories supplied to the linker.
Verify the folders/paths you provide to the linker and verify that the file the linker is looking for is in one of the directories that you're providing to the linker. You have to provide directories to the linker because you're telling the linker "you can look in all of these places for the libraries my project needs". If you specify none, it's got nowhere to look. :(
Example:
I'm trying to link the shared library of boost thread into my application.
System: Windows8
IDE: Visual Studio 2010
I build the boost library using:
b2 --with-thread --build-type=complete link=shared
I can see the
boost_thread-vc100-mt-gd-1_55.dll
boost_thread-vc100-mt-gd-1_55.lib
and other file inside the stage/lib directory
I've added the path to Additional Library Directories and Input in linker option as:
Additional Library Directories: C:/boost_1_55_0_dyn/stage/lib
Input: C:\boost_1_55_0_dyn\stage\lib\boost_thread-vc100-mt-gd-1_55.lib
I don't know why on the earth Visual Studio is looking for libboost_thread-vc100-mt-gd-1_55.lib. I haven't mentioned the libboost_thread-vc100-mt-gd-1_55.lib anywhere in the properties or any place. I even search all my files and folders inside the project, libboost_thread-vc100-mt-gd-1_55.lib is not mentioned anywhere.
Well I forgot to put BOOST_ALL_DYN_LINK in preprocessor definition. If the BOOST_ALL_DYN_LINK is not defined, boost looks for static library, that is why its looking for libboost_thread-vc100-mt-gd-1_55.lib
This is additional information to the answer Pritesh already posted, but I'm new here so I can't comment.
It boils down to compatibility between your VS project settings and the way the boost libraries were built. It gets a little tricky because boost and VS do some autolinking for you. Check out the file …\Include\boost\config\Auto_link.hpp. It explains the algorithms and macros that will cause libraries that you didn't explicitly include to show up in your project.
For example, BOOST_ALL_DYN_LINK is used to help determine if the boost library name should have "lib" pre-pended to the name during autolink.
Additionally ,
If you are using cmake and qibuild you can try this :
It automatically links with the corresponding libraries and make their headers available.
qi_use_lib(yourProgramName your libraries)
like this:
qi_use_lib(getimages ALCOMMON ALPROXIES ALVISION OPENCV2_CORE OPENCV2_HIGHGUI OPENCV2_IMGPROC)
we're building a cross-platform utility which must have a small footprint. We've been pulling header files from boost as and when we need them but now we must link against some boost C++ thread code. The easiest immediate solution was to create our own custom library using CMake's "add_library" command to create a static library composed of some boost thread source files. These compile without any problems.
The difficulty arises when I try to link to this library from an executable. Visual Studio 2008 returns an error saying that it cannot link to "libboost_thread-vc90-mt-sgd-1_40.lib". What really puzzles me is that I've grepped through all the source code and CMake config files and I can't find any reference to this libboost library, leading me to think that this has been autogenerated in some way.
This works OK in Linux, can anyone point out why I'm experiencing these issues in Windows?
#Gearoid
You found the correct reason for your problem, but not the correct solution. The BOOST_AUTO_LINK_NOMANGLE is an internal, i.e. for library authors, definition to control the auto-linking. The user level definition is BOOST_ALL_NO_LIB which when defined disables the auto-linking feature for all Boost Libraries code you use. This is described in the user.hpp configuration header (see user.hpp near the bottom and the Boost Config documentation). You can also control this on a per library level as describe in that header.
Ok, well, it turns out that Boost uses this auto-link feature for Visual Studio which embeds references to a mangled (ie, platform-compiler-mult-threaded, etc) boost library name.
The header file which controls this is called "auto_link.hpp" which lives in the config directory of the boost include tree. There's a special preprocessor definition called "BOOST_AUTO_LINK_NOMANGLE" which toggles this behaviour.
Another triumph of mediocrity for Microsoft.
I'm trying to use a static library created by me in Visual C++ 2005 (unmanaged C++). I declare one function "int myF(int a);" into a .h file, I implement it in a .cpp file, I compile it - the .lib file is produced.
I create a new project (a separate solution) in VC++ 2005 (also native C++), I add the paths for the include file and the lib file; when I invoke the function myF the linker reports an error: "error LNK2019: unresolved external symbol _myF referenced in function _main". if I create the client project in the same solution as the library project and then add a reference to the library projects, it works, but I'm not going to implement everything like this, but rather to add external libraries to my projects...
What is wrong?
Thank you.
You need to also include the actual .lib file in your 2nd project (not just the path to it).
There should be an option in the linker settings to do this.
It is not sufficient to list the folder in which MyStatic.lib can be found. You have to explicitly tell the linker that Dependant.vcproj is using MyStatic.lib.
In VS2005 you do this by project properties->Linker->Input->Additional Dependencies. You can also sprinkle some preprosessor stuff in the .h file to tell the compiler to tell the linker to use MyStatic.lib.
Edit:
The preprocessor magic goes like this
#pragma comment(lib, "MyStatic.lib")
(EDIT: This was a response to the question of getting the /NODEFAULTLIB error in link phase which has now been deleted... shrug)
You are mixing compiler settings if your are getting the defaultlib error. For example, if you build your library in debug and the build your main in release, you will get this error since they are built to use different versions of the CRTL. This can also happen if you use different settings for linking with the C Runtime as a object library or as a DLL. (See the C/C++ options, the "Code Generation" section, under the "Runtime Library" setting)
In many projects there isn't much you can do if you can't correct the settings of the library (for example, 3rd party libraries). In those cases you have to use the /NODEFAULTLIB switch which is a linker option in the "Input" section called "Ignore Specific Library".
But since you are in control of both the main and the library, build a debug and a release version of your LIB file or make sure your "C/C++;Code Generation;Runtime Library" settings match in both projects.
Try setting additional dependencies in the linker input for a project properties.