While compiling a DLL in Visual Studio 2013 I include some boost (1.58) header files. One is <boost/system/error_code.hpp>. As it is known this will require to link to a boost lib, by default. However, I want to use the header only variant and not handle yet another library. For that I figured out how to make it work on Linux + Mac. However, I cannot get this to work on Windows. The linker always wants that additional library (libboost_system-vc120-mt-gd-1_58.lib)
What's the trick in Visual Studio to avoid linking to that lib?
Ok, I found it myself. This is not mentioned anywhere in questions about boost libs including on Windows. But if you search for disabling boost auto linking (which is actually the culprit including the libs) you will find the solution: define BOOST_ALL_NO_LIB at project level (in addition to the header only flag mentioned in the other question).
Related
I am trying to create a C++ project in Visual Studio 2013 that has CGAL and Boost (and a couple of other libraries) as dependencies. I preferably like to link to these libraries dynamically. Also, I'd like to link to the "Release" versions of these libraries for performance reasons (not the "Debug" versions).
Starting from an empty C++ project, I added the path to header files of the aforementioned libraries as shown in the image below:
Inside the linker options, I then added the directories that contain the DLL and lib files of the external libraries. (CGAL directory contains CGAL's compiled DLL files along with lib files).
At this point, I have not added a single "lib" file "Additional Dependencies" dialog:
Now something weird is going on and I cannot explain why. If I try to build the project as-is (under the "Debug" configuration), I get a LNK1104 error about the linker not being able to find CGAL-vc120-mt-gd-4.7.lib. I know that the error means I should add the lib file in "Additional Dependencies" dialog...
But wait... WHAT...?!!
How does Visual Studio know how to automatically link against this lib file?! Worse yet, how does it know it needs the "debug" version of the library? (With the gd suffix). Also, how does it know I compiled CGAL with VS2013!!??
At first, I though the project was inheriting properties from some preset property sheets somewhere in my system. But I am certain that's not the case as this behavior shows even with a project created from scratch.
My main question is, how would you force Visual Studio to link against the "Release" version of this library? (eg. CGAL-vc120-mt-4.7.lib)
Side question but related: Am I even linking against the DLL files? How can I be certain that I am in deed doing dynamic linking and not static linking?
This is probably happening due to the #pragma comment(lib) mechanism - eg see What does "#pragma comment" mean?
This is a way of the compiler emitting instructions for the linker so that it can decide between multiple versions of a library depending on the compiler version. In this case it means that it can automatically pick up the correct version of the library (debug vs release, vs2013 vs vs2015, MT vs MD, etc). When you added the explicit reference to the library in Additional Dependencies then it is now trying to look for two files.
So, to fix the problem, remove it from Additional Dependencies and let VS pick the right library. If you are getting the LNK1104 error then it suggests that either the link library path isn't set up correctly, or you don't have the CGAL library file it's looking for. You can increase the verbosity settings for the linker in the Project Options to get more detail about what's happening.
I'm trying to compile one of my projects on Windows 7, using Visual Studio 2013. I've installed Boost 1.53 and setup the solution using cmake.
What happens is that now the compiled libraries of boost are in the form libboost_*-vc120-mt(-gd)-1_53.lib. In the linker project options, under the input tab, I have verified that the libraries that I need are there, and in fact the compiler is able to correctly read them.
However, for some reason that I absolutely can't understand, the linker is also trying to find libraries compiled as vc110. For example:
error LNK1104: cannot open file 'libboost_filesystem-vc110-mt-gd-1_53.lib'
The Platform Toolset that is listed in the project option is "Visual Studio 2013 (v120)". I couldn't find any reference to vc110 in any of the project options. Can you help me understand what is happening?
This post thankfully solves my question. I wasn't able to find it before. The solution is to edit the boost/config/auto_link.hpp because the code inside is not able to handle vc120, and ends up suggesting vc110
How do I specify, which version of boost library to link to?
The library name is autogenerated in the boost header version.hpp
Possibly the version wasn't rebuilt, or you are pointing at the wrong header version?
Instead of patching the config file try just defining a macro before the header inclusion .. this is what I did in my project
//#define BOOST_LIB_TOOLSET "vc100"
//#include
The Gameplay Project distributes a set of static libraries of all it's dependencies. The libraries they include will link in a debug or release build of an application. I ran the strings command on their lib and compared it to one I compiled. The linker directive /FAILIFMISMATCH:"RuntimeLibrary=MD_DynamicRelease" is set in my library, but not theirs.
How did they compile their library this way?
Edit: Clarification
I failed to mention that this occurs on the next branch, which uses libs compiled for VS2012. The _MSC_VER of the libraries is 1700.
I am aware that you shouldn't link different versions of the CRT, but I'm wondering how they were even able to compile it this way.
It seems MS has started adding /FAILIFMISMATCH:"RuntimeLibrary line from vs2012. /FAILIFMISMATCH itself is introduced in vs2010. I've chekced Gameplay Project sln file and it is using vs2010. Try to use vs2010 and see if the directive is gone.
I think you already know this but it doesn't really matter if the directive is there or not because you must match the runtime library compile option anyway.
I ran into a strange problem with a Visual Studio 2008 project I was working with recently.
I am trying to compile a new static library that uses functions from another static library. (Let's say Lib1 is my static library project, and Lib2 is the lib file that Lib1 depends on).
I am able to build lib1 without issue; It includes the header files for lib2 and calls its functions, and there are no problems.
The problem is when I build a separate test project that has Lib1 as a dependency; it won't build and I get linker errors. The unresolved externals are the functions I am trying to call within Lib1 that are from Lib2.
This is all fixed when I include Lib2 in my test project as well.
This all makes sense to me of course; I can test that Lib2 is not being built into Lib1..
My question is: is there a way to do this? I would ideally like to be able to deploy Lib1 as a standalone lib without requiring Lib2. (Lib2 is actually just a Lib from the Windows Platform SDK, so it's not really a big deal...)
Is this not allowed because it would allow people to "hide" third party libraries in their own, or something?
What would be a professional approach to this problem?
Thanks!
--R
I would not advise using a librarian to take Windows' library contents into your own library -- it's likely that that's against the license.
I see two possibilities
Documenting the dependency
Using a #pragma in your .h file that requests the .lib to be linked against. If VS can find it, it's the same as including it on your link line.
http://msdn.microsoft.com/en-us/library/7f0aews7(VS.80).aspx
#pragma comment(lib, "libname.lib")
You need to use a tool called a librarian to do this. A librarian allows you to create and modify library (.lib) files. In visual studio check under the Librarian section of your project properties. A command line version also comes with visual studio (lib.exe).
Just document the dependencies of your lib.
As long as the library you depend on is available to anyone that could use your library, this is the preferred solution. Especially considering that the library user could also depend on this platform SDK lib - if you had it embedded then he'd get funny linker errors with multiply defined symbols.
This is a fairly normal problem - you wouldn't normally attempt to include 'lib2' into 'lib1' but simply document that it's required to be linked against in order to work. There is nothing wrong with declaring the use of other libraries (apart from any licensing issues of course) so you are already doing the right thing.
If you really want to do this, you can extract the .obj files from Lib2 and add them to Lib1.
See How to Extract .OBJ Routines from .LIB Files Using LIB.EXE -- I hope it is still relevant for VS2008.
Instead of simply documenting your dependencies, use #pragma comment(lib, 'lib2name') in your code to make the linker pull in the other library automatically. Since you said you're using a standard library that comes with the SDK, this should eliminate all burden on the application.
We have a large project using VS2008 and boost 1_42. I'm trying to upgrade to VS2010 and boost 1_44. I installed VS2010 and boost 1_44 and converted the project. Now I am trying to build, and everything compiles, but fails when linking:
LINK : fatal error LNK1104: cannot open file 'libboost_thread-vc90-mt-1_42.lib'
I have changed the include and lib directories to point to the new boost 1_44 files and I have renamed the old boost 1_42 directory.
Why is the linker still looking for a vc90-1_42 file, when it is only using 1_44 headers? Is there a way that I can determine WHY the linker wants this file? The linker obviously thinks it needs the file, but why?
I have cleaned the project and I am re-building to ensure any old build files are erased.
I've run into exactly this problem a couple of times too. It's usually been some old temporary files but like in your case cleaning didn't always do the trick straight away. Does your project include any static libs that might have been built with 1.42?
Something you can try which may or may not be helpful in tracking down your issue:
Rename the old boost directory back to it's original name
Clean the solution
Under C/C++->Command Line->Additional Options add "/showIncludes"
Under Linker->Command Line->Additional Options add "/verbose:lib"
Rebuild all
Then when you build you'll be able to see at which point 1.42 headers are included, etc. in the output window. Somehow doing this helped me in tracking down where the problem was.
Along with changing the lib directory, you need to change the name of the boost library. That's in the Linker | Input section of the project settings.
Your added comment makes it clear that the dependency on the Boost 1.42 library was being created indirectly by another library that hadn't been rebuilt.
For this you basically have two choices: either add that library as a project to your main solution, and make sure it has enough dependency information that it'll be re-built when you upgrade Boost, or use the /Zl compiler switch when you build your library. This tells the compiler you're building a library so you do not want to embed library dependencies like this.
Boost uses
#pragma comment(lib)
command to inform the linker of libraries it needs to link with. It is not an error. If Boost says you need it, it's likely you do.
On How can I find out why the linker wants this file?
There are programs which will go through your app and dlls/libs and report the content of manifests and what the binaries report they depend on. You could then scan the report for the unexpected libraries being included. We used this mainly to find libs including the previous version of the VC runtime.
Have not used the one we had in about 5 years though, now if only I could remember the name of the app!
DependancyWalker (depends.exe) will allow you to see dependancies of dll/exe but not static libs.
You could open each binary as a 'file' in MSVS and look at the manifest content by hand, but I imaging this would be a bit painful. I've not tried this with a static lib.