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.
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.
vs report a error such as:
can not find xxx.lib
How do I check out why vs need to link xxx.lib? Is there a trace log? My project have not use boost.regex, but vs report a error says can not find regex.lib. So I want to find out which part of code refer to regex
LNK error: LIBCMT.lib: xxx was already defined in LIBCMTD.lib
How do I check why vs also link yyy.lib even this is a debug build? I have 2 projects, they link to same libs, all libs and project itself was /MTd. But one of them will report above error, I think it shouldn't link LIBCMT.lib because it is a release version lib, and another project is OK so the lib file was build correctly
VS can show the link trace?
1) Let's start with how the linker actually knows what to link with. Basically there are 2 categories:
Libraries specified in the project settings in the linker options as additional inputs
Libraries added in code with precompiler directive #pragma comment (generally the same thing as above but people have different tastes)
Otherwise you just get information about missing symbols but not the actual library they are from. What you can do to help is under visual studio linker options set Show Progress to For Libraries Searched (or just /VERBOSE:LIB linker flag), that will actually show you what dependencies are added after each lib is loaded, this also helps with point 2) to see which library loads which run-time.
2) Already mentioned in 1) that you can make the linker show library load progress, otherwise if a dynamic C run-time is used in the external library you are linking against you could use Dependency Walker to examine the dependencies of the library and find if the C run-time dll that is needed is debug or release by 'd' suffix in the dll name. If the library is already linked with static run-time then I guess only the linker errors will warn you. But I think that most serious libraries are correctly packed and structured so that you will be able to tell which files contain the debug version and which the release. If the library has only release version, well than that's another story. But i mean still, you can reconfigure the Debug configuration of your project to actually link against the release run-time to satisfy the external library, of course this prevents some debugging features, debug heap, etc.
For the missing boost regex library problem, I think the cause is due to boost's default autolink behaviour. If you include one of the headers of some of the boost libraries (not all of them, but regex is one of them), then these will cause Visual Studio to automatically link against the library. It uses a special pragma of the form:
#pragma comment(lib, "regex")
This has the effect of automatically adding a flag to the linker command. However, it's only picked up during compilation and so you won't see it in the project properties. In the case of boost, the solution to this is quite simple - find boost/config/user.hpp and uncomment the line
#define BOOST_ALL_NO_LIB
This will turn off the autolink behaviour for all libraries. Alternatively you can use #define BOOST_REGEX_NO_LIB to change this just for the regex library.
To solve the second problem, you need to find out which library is linking against the release build. Try selecting all projects in the solution and open Properties -> C++ -> Code Generation. You will probably find that the Runtime Library setting will be blank (because the option is different for some of the libraries. Force it to the correct threaded/single-threaded Debug option and rebuild.
I have an MSVC++ project consisting of an executable, several own static libraries and some precompiled static third party libraries. The exe uses incremental linking in order to speed up build time.
When I change a .cpp file within the executable project, compiling + linking is very quick (<10s).
However, when I change a .cpp file within one of my own libraries, the executable project appears to be doing a full link against every library it uses.
I'm not so sure anymore if it is a full link in fact, but from the "vc90.pdb not found" Linker Warnings, I can tell that it links against some external libraries which have not changed at all.
Here's an example of the project structure:
Precompiled third party libraries ExtLib1, ExtLib2 and ExtLib3
Own Library MyLib, using third party lib ExtLib1
Own Exe MyExe, using MyLib and ExtLib1-3
Changing a .cpp file in MyLib would then lead to MyExe being linked to MyLib, ExtLib1, ExtLib2 and ExtLib3, even if Incremental Linking is turned on.
A full link takes around 5 minutes in my project, so I'm asking: Is there any way to re-link only the changed library?
This is a introduction to incremental linking. It lists situations that will cause a full link. One of them is "An object that was compiled with the /Yu /Z7 option is changed.", check if your MyLib caught it.
When a static library changes there will always be a full link for the executable, at least in Visual Studio 2013, and you will probably get something like this in the output window:
2>Link:
2> LINK : library changed; performing full link
Good news though: I did a quick test in Visual Studio 2015 and incremental linking seemed to work as expected.
Source: lots of experimentation and looking around, having had the same problem. Also, this: http://www.pcreview.co.uk/threads/incremental-linking-and-multiple-projects.1431266/ , specifically:
This is by design. We can't incrementally link when a static lib changes.
That was never supported before either.
Ronald Laeremans, Visual C++ team
Edit - it's confirmed that VS 2015 has incremental linking when using static libraries: http://blogs.msdn.com/b/vcblog/archive/2014/11/12/speeding-up-the-incremental-developer-scenario-with-visual-studio-2015.aspx .
I have a simple C++ program. I want to just build the exe and give it to a person on another complete non-development box. Is there a way to build such a simple, single-source file to an executable in Visual Studio without needing all the crap ? I have changed the program to compile in MT mode, instead of MTD which statically linked the msvcr.dll file, but now it is looking for msvcp.dll file. How can I compile so that my executable either 1) doesnt include all this junk or 2) statically links it all so that I have exactly one file to transfer to another Windows PC to run
Thanks
If compiling with /MT is requiring msvcr100.dll, something included in your application is probably trying to link with it, possibly a third party component. I would check any third party libraries and related.
MSVCP100.DLL is the C++ standard library. You might want to double check that it's not looking for MSVCP100D.DLL, which is the debug version; mixing release and debug mode libraries could cause this.
MSVCRT100.DLL is the C run-time library, and MSVCP100.DLL is the C++ standard library. Both should go away if you build with /MT, in that case static versions of these libraries should have been used.
My guess is that you either did not fully rebuild your app after switching to /MT, or that one or more files in your project have custom settings that include /MD. You may want to open the properties dialog box on the page that shows the /MT and then click on all your source files one by one to verify that none of them still show /MD.
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.