I have a template VS .NET 2003 project, which colleagues copy and customise when developing their software.
It appears the template was altered a while back to set the IgnoreSpecificLibrary property to have libcmt.lib for both release and debug builds (i.e. for both release and debug, the build should ignore libcmt.lib in the linker).
Some projects based on this have since been built, with the release build pulling in libcmtd.lib (evident by looking through the project .map file) which appears to have caused some runtime issues (i.e. a dialog window being flashed up as though a breakpoint had been set).
Does setting IgnoreSpecificLibrary to exclude libcmt.lib automatically make the project link against libcmtd.lib?
What is weird is that building the template (with the incorrect setting) links against libcmt.lib whereas some of the customised projects (though not all) link against libcmtd.lib.
Any ideas?
This is what happened:
After compiling the linker takes your object-files and create among others
a symbol table ,which has symol-request that have not been fullfilled.
Then the linker goes through your list of libraries trying resolve those
unfullfilled symbols. Since you ignore libcmt.lib ,your third-party library
has left or added some unresolved symbols and it contains a linker request
to resolve those from licmtd.lib (and maybe other libs as well) ,since it
was compilled with debug option.
If you hadn't ignored libcmt.lib those symbols would most likely be resolved
by libcmt.lib and there was no need to pull in stuff from libcmtd.lib (even though
it would be looked at to resolve other symbols that were still unfullfilled)
You may try to igmore libcmtd.lib also. If you now get unresolvd externals then
it was probebly no a good idea to ignore libcmt.dll.
Many projects ignore the libcmt.lib, because it conflicts with the dynamic version msvcrt.lib.
Ignoring libcmt in the linker make the project compile with msvcrt.lib
Related
All of a sudden, my program got link errors like below:
libcpmtd.lib(xlock.obj) : error LNK2038: 'RuntimeLibrary' unmatched.The value 'MTd_StaticDebug' is different from that of [project x], which is: 'MDd_DynamicDebug'
Since this error suddenly appeared on multiple computers, I believe this was not caused by unintended modification of any file.
Version: Visual Studio 2013
Question-1:
Could you give any hint about the reason of this error and how to solve it?
What I did:
I remove the libcpmtd.lib from the import library list of project setting, then the build error disappeared and everything was OK.
But, I am not sure what libcpmtd.lib is for?
Google told me there is CRT inside, but what are the content specifically?
Perhaps this library was added and then not relevant from some point of time.
Question-2:
what is in side libcpmtd.lib? I want to figure out what I might have lost after I removed the lib.
These are the C++ standard runtime libraries. With Visual C++, you have 2 options, which give you 4 permutations of the library it links to.
Debug v.s. Release
As it suggests, do you want the C++ runtime lib that has additional error checking?
Static v.s. Dynamic
If you happen to be compiling only a simple exe, then linking to the library statically should be fine. If however you have a large project consisting of multiple DLL's, then it makes sense to load the CRT dynamically (so it can be shared between the DLL's, rather than being duplicated into each one).
So what you have is a mis-configured build. You'll need to check the C/C++ Runtime Library settings for each library, DLL, and exe within your project (which you can find in your project settings, under C/C++ -> Code Generation).
You will need to make sure that each one links to the same runtime library (i.e. Debug DLL for all debug settings, Release DLL for all release settings).
If that doesn't fix it, then there are two other possible causes:
You have started linking to a 3rd party library, and that's the cause of the CRT mis-match. Most libs ship debug and release builds for this reason, so hopefully you'll just need to update the libs you are linking to.
You are inadvertently pulling in a Debug lib into a release build (or a release build lib, into a debug exe). For this you will need to check all of the additional library directories, and/or check to make sure all of the debug & release output directories are correct (i.e. you aren't accidentally compiling a debug lib into a release build folder).
im trying to build my project and I want to link the windows CRT statically, but I find some errors trying to linking it,
I've included in the linking list these ones:
libcmt.lib
LIBCPMT.LIB
libucrt.lib
libvcruntime.lib
but I get these linking errors, saying that these symbols are missing:
__imp_copysignf
__imp__aligned_free
__imp__aligned_malloc
__imp_modf
__imp_modff
I've already added libucrt (which is where must be malloc functions but still giving errors), what lib am I missing?
EDIT: Im using Visual Studio 2017 15.4.4 targeting Windows 10 ver.10.0.16299.0
Double-check that you have also set the /MT compiler flag. If it is not set, it is possible that it defaults to dynamic linking setting. In that case, _MT preprocessor define is missing, which causes the compiler to use calls to dynamic runtime functions. You can see the __imp__ prefix that normally comes from DLL import libraries.
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 am trying to build a release version of my project. Our prof made us create a static library which i built using debug version.
then i made a release version of that static library using /mt as my c runtime
now in my test application (release version) I use the same runtime option and add that static library and also ignore the libcmd.lib in the ignore settings for the linker.
i resolved most of the problem
this is the last part
lnk4075 /edit and continue due to /opt:icf specification compositelib.lib (my staticlib)
lnk2001 unresolved external symbol _winmain#16. libcmtd.lib
these are the last two that i can't seem to figure out.
add libcmt.lib to ignore list for release version.