I'm going to ask this question, and then answer it myself.
I'm, aware that its a newbie question, but as it took me approx. two days to find the correct answer, I'll post it anyway.
So much for disclaimers - this one is dedicated to all you newbies out there:
I've go an MFC project in VS 2010, and I needed to add some 3rd party static library. All went well, both projects compiled and my project managed to reference the library. Then, when I included some header file from the library in my project, I got numerous a linker warnings, about functions in the C Run-Time library, e.g.:
Warning 9 warning LNK4006: _sprintf already defined in libcmtd.lib(sprintf.obj); second definition ignored C:path\to\my\project\MSVCRTD.lib(MSVCR100D.dll)
Thinking 'what the hell', I tried running my project, and it did run, until it came across a code line which tried to write into some file using 'fostream', and then it crashed with some scary heap corruption exception.
Searching S.O., I came across some related issues, none of which exactly match my problem:
Link libraries with dependencies in Visual C++ without getting LNK4006
How do you build a debug .exe (MSVCRTD.lib) against a release built lib (MSVCRT.lib)?
I almost wrapped the external library in a dll, before I stumbled across the answer.
My happy ending is that I've stumbled across the correct answer in Microsoft support article: How to link with the correct C Run-Time (CRT) library .
Apparently, I violated the following rule, as stated in the articel:
A reusable library and all of its users should use the same CRT library types and therefore the same compiler switch.
Meaning that I should have used the same C Run-Time (CRT) library for both project and 3rd party library. Selecting CRT in VS 2010 can be done by: right-click project_name --> properties (the properties window opens) --> C/C++ --> Code Generation --> Runtime Library. Use the pull-down list and select the runtime library, according to the table in the article (single-threaded, static multi-threaded or dll multi-threaded, release or debug).
After configuring all projects, re-compile them, and (hopefully) the warnings are gone.
Related
I was working on a MS Visual Studio project and noticed that the Debug build was Linking to a Release library (DLL), when a Debug library with the same name was also available. I switched the path to Link the Debug library, and it seems to still work. Is there any way to know if my change was correct?
Additional Information:
Using the debug DLL triggers a small memory leak that wasn't triggered with the release DLL. Or possibly that is debug related cache data. That leak made me question if it was including the lib headers without _DEBUG somehow. Thus this question.
It is the preferred way to link Debug builds of your program with Debug version of external dynamic libraries as it guarantees that uniform Visual C++ runtime libraries will be used. Mixing libraries built in Debug and Release mode will result in both Debug and Release VC++ runtimes being linked and annoying linker warnings about multiple symbol definitions in conflicting Debug/Runtime libraries.
Sometimes it may be inevitable as i.e. only Release version of some external library may be available. Hence in VC++ there are linker settings allowing to ignore some specific libraries. So you may start checking in the Linker-Input settings of the Debug build if such ignores are already defined for existing conflicts. With some luck you might be able to remove them now.
If using the Debug version of some library breaks the whole program it might be an insight how to improve the whole system, it is that what a Debug build is for anyway.
Assuming that it is the right library (as in the same code compiled to a different configuration), you are right to link to the debug dll on your debug configuration (and should link to the release dll on your release configuration).
The differences tend to be related to the optimisation level (Debug is usually compiled without any optimisation at all) and any symbols that might be included to make it easier to develop with and maybe step into.
I'm trying to make a binary that can be run on any windows machine without the visual c++ stuff installed (I'm assuming that's what MSVCP120D.dll is however my searching was not very fruitful as to what this actually is). I made a game for an assignment and wanted to have other people (non-devs without VS stuff installed), help me test it but they kept getting errors saying that the above dll is missing. I'm not using any Visual C++ stuff and have the /Za flag set to ensure that it's just ANSI C++. Does Visual Studio support compiling ANSI C++ and if so how do I go about making it not use Visual C++ stuff, if it doesn't support this what compiler should I use?
As you can see here, the MSVCP DLL is the platform's implementation of the C++ Standard Library. In short what that means is you cannot distribute your application without needing the "stuff" that these libraries provide. All compilers regardless of platform would need some kind of implementation of the Standard Library. Typically this is distributed in the form of libraries.
However you can distribute your application so that the "stuff" is built in to your program directly, rather than being shipped in a separate DLL. In order to do this, you must statically link your application to the Standard Library.
There are a few ways to accomplish this. One way is in Project Settings. In "Project" > "Configuration Properties" > "C/C++ Code Generation" > "Runtime Library", choose "Multithreaded (/MT)" as opposed to "Mutithreaded (Static)".
By the way, the "D" in "MSVCP120D.dll" you mentioned above means "Debug." This means that you are trying to distribute a debug build of your program. You should (almost) never do this. Distribute release builds instead.
You have three options (in the order I'd recommend):
Don't statically link, instead get people that want to run your game install the visual studio re-distributable package. 32-bit VC 2010 version here: http://www.microsoft.com/en-us/download/details.aspx?id=5555
Statically link the CRT (the dll you don't want to require at runtime) see here for details: How do I make a fully statically linked .exe with Visual Studio Express 2005?
Build an app that doesn't even use the CRT at all. Here you will have to implement your own operator new that calls HeapAlloc(), and operator delete that calls HeapFree(), its an interesting challenge ;). To do this you tell the linker to ignore all default libs.
Build with the static runtime libraries rather than the DLL versions.
Go to Properties, C/C++, Code Generation, Runtime Library and select /MTd or /MT rather than the /MDd and /MD options.
Configure your project to link against the runtime statically rather than dynamically.
First of all the D on the end of the name indicated a debug build. If you make a release build then it will need it without the D. This is important because microsoft do not allow the debug libraries to be distributed without visual studio.
The machine you are trying to run the program on may already have the release runtime installed as lots of programs use it. If not then install http://www.microsoft.com/en-us/download/details.aspx?id=30679 on the machine ( I think that's the right one but can't check at the moment)
You'll want static linking, that 'builds in' the external library calls into your binary. It does have the added affect of larger binary file, but in your case that doesn't sound like that big of a deal.
On a side note, MSVCP120D.dll is the Microsoft Visual C++ 12 debug DLL (dynamic link library) that contains all of debug C++ libaries (i.e. iostream, string, etc). That library is what you would be 'baking in' to your final binary.
Hope that helps.
I encountered this error when I tried to execute my exe on a different machine that had a newer version of Visual Studio on it. You need to change the project properties and re compile in order for this to go away.
To do this:
Open up solution that you are trying to run
Right click on the Project file - > Properties
In Configuration Properties and General, Ensure Platform Toolset is configured to be the correct compiler on your machine. If it is not correct, it should give a message next to it saying that it's not installed.
Build and run the code again and you should no longer get the issue.
Brief introduction:
I am refactoring win32 application, I use VS 2008.
The application consists of both of my own dll and 3-rd party dll`s.
Issue:
When I run the application in the debug mode and execute some action the error is raised: the application programm has triggered a breakpoint, heap is corrupted.
Actions undertaken:
I have searched the internet and found that this error may be because of different build flags (multi-threaded debug /MD and multi-threaded debug dll /MDd) were used for dlls within the project(which results that they use different c runtime libraries, and for each library own list for work with memory is maintained this therfore can lead to the heap corruption).
I have checked my dlls - they all have the same flag: debug multithreaded dll. So I think that one of the 3-rd party DLL maybe was built with multi-threaded debug flag.
Questions:
Is it possible to find out with what flag 3-rd party library was
built, if so how can I do this.
How can I sort you my issue of
different build flags?
Is my guess about that error is due to
different build flags is correct?
Is it possible to find out with what flag 3-rd party library was built, if so how can I do this
Yes. C or C++ DLLs built with Visual Studio versions 2005 and 2008 require a manifest that states what version of the C runtime DLL they need. You can see it with VS, File + Open + File, select the DLL and open the node labeled "RT_MANIFEST". Resource ID 2 is the manifest that states the type and version of the CRT. It should match yours. Export it to make it easier to read. If it is missing then it either wasn't built with /MD or used a completely different version of VS, which in itself is bad news.
How can I sort you my issue of different build flags?
You can't. You'll need to contact the 3rd party and request a build that's compatible with yours.
Is my guess about that error is due to different build flags is correct?
It is possible but not terribly likely. Having a mismatch does not automatically cause a crash, a programmer can certainly design the DLL interface so that's never an issue. You can typically tell from the function signature and documentation. The problem case is where the DLL allocates an object and you are supposed to release it. It will be obvious when the function returns a pointer. Or a standard C++ class library object like std::string. Less obvious is when it throws an exception. Such a problem is also highly repeatable, it will bomb consistently, not occasionally.
The biggest mistake you are making is asking this question here. You should be talking to a programmer employed by that 3rd party that has worked on this DLL. He'll know the exact answer to your questions and can very easily solve your problem. If you cannot get this kind of support then you should not be using these DLLs, they'll make your life miserable for a long time to come.
Problem:
I'm trying to use a library named DCMTK which used some other external libraries ( zlib, libtiff, libpng, libxml2, libiconv ). I've downloaded these external libraries (*.LIB & *.h files ) from the same website. Now, when I compile the DCMTK library I'm getting link errors (793 errors) like this:
Error 2 error LNK2005: __encode_pointer already defined in MSVCRTD.lib(MSVCR90D.dll) LIBCMTD.lib dcmmkdir
Error 3 error LNK2005: __decode_pointer already defined in MSVCRTD.lib(MSVCR90D.dll) LIBCMTD.lib dcmmkdir
Error 4 error LNK2005: __CrtSetCheckCount already defined in MSVCRTD.lib(MSVCR90D.dll) LIBCMTD.lib dcmmkdir
Error 5 error LNK2005: __invoke_watson already defined in MSVCRTD.lib(MSVCR90D.dll) LIBCMTD.lib dcmmkdir
Error 6 error LNK2005: __errno already defined in MSVCRTD.lib(MSVCR90D.dll) LIBCMTD.lib dcmmkdir
Error 7 error LNK2005: __configthreadlocale already defined in MSVCRTD.lib(MSVCR90D.dll) LIBCMTD.lib dcmmkdir
Error 8 error LNK2005: _exit already defined in MSVCRTD.lib(MSVCR90D.dll) LIBCMTD.lib dcmmkdir
Documentation:
This seems to be a popular error for this library so, they do have a FAQ entry addressing this issue which ( http://forum.dcmtk.org/viewtopic.php?t=35 ) says:
The problem is that the linker tries to combine different,
incompatible versions of the Visual
C++ runtime library into a single
binary.
This happens when not all parts of your project and the libraries you
link against are generated with the
same code generation options in Visual
C++.
Do not use the /NODEFAULTLIB workaround, because strange software
crashes may follow. Fix the problem!
DCMTK is by default compiled with the "Multithreaded" or "Multithreaded
Debug" code generation option (the
latter for Debug mode).
Either change the project settings of all of your code to use these code
generation options,
or change the code generation for all DCMTK modules and re-compile.
MFC users beware: DCMTK should be compiled with "Multithreaded DLL" or
"Multithreaded DLL Debug" settings if
you want to link the libraries into an
MFC application.
Solution to same problem for others:
Huge Amount of Linker Issues with Release Build Only says:
It seems that your release build is
trying to link to something that was
built debug. You probably have a
broken dependency in your build, (or
you missed rebuilding something to
release by hand if your project is
normally built in pieces).
More technically, you seem to be
linking projects built with different
C Run Time library settings, one
with "Multi-Threaded", another one
with "Multi-Threaded Debug". Adjust
the settings for all the projects to
use the very same flavour of the
library and the issue should go away
Questions:
Till now I used to think that Name mangling is the only problem that may cause linking failures if its not been standardized. Just now I knew there are other things also which can cause same effect.
Whats up with the "Debug Mode" (Multi-Threaded Debug) and "Release Mode" (Multi-Threaded)? What exactly is happening under the hood? Why exactly this thing is causing linking error?
I wonder if there is something called "Single-Threaded Debug" and "Single-Threaded" which again causes the same thing.
Documentation talks something about "Code Generation Options". What Code Generation Options? WTH are they?
Documentation specifically warns us not to use /NODEFAULTLIB workaround. (example /NODEFAULTLIB :msvcrt ). Why? How would I cause troubles? what exactly is it?
Please explain the last point in the documentation for MFC users. Because I'm going to use MFC later in this project. Explain Why should we do it? What troubles would it cause if I don't.
Anything more you'd like to mention? I mean regarding similar errors. I'm very interested in Linker & its problems. So, if there are any similar things you can mentions them or some keywords atleast.
Whats up with the "Debug Mode"
(Multi-Threaded Debug) and "Release
Mode" (Multi-Threaded)? What exactly
is happening under the hood? Why
exactly this thing is causing linking
error?
The linker drags in libraries for several different reasons. The simplest is that a library is listed on the linker command line, or in the linker answer file on the linker command line. But any object files, whether compiled in your project or packed into a library, can also contain linker options including requesting particular libraries be linked in. In fact, the Visual C++ compiler automatically embeds such linker options matching the project options you use when compiling.
At link time, all the linker options from all object files and objects in static library files get combined. If more than one CRT library filename is requested, the linker reads in all of them and them you get naming conflicts, where the linker doesn't know which one to use.
I wonder if there is something called
"Single-Threaded Debug" and
"Single-Threaded" which again causes
the same thing.
There used to be, but the last few versions of Visual C++ have only shipped multi-thread compatible libraries.
Documentation talks something about
"Code Generation Options". What Code
Generation Options? WTH are they?
Look inside your project options.
Documentation specifically warns us
not to use /NODEFAULTLIB workaround.
(example /NODEFAULTLIB :msvcrt ). Why?
How would I cause troubles? what
exactly is it?
If you use /NODEFAULTLIB, all the linker settings stored within object files and objects in libraries get ignored. You'll end up with no runtime library and maybe missing other libraries. You can add them back in by hand, but it's still a big mess.
Please explain the last point in the
documentation for MFC users. Because
I'm going to use MFC later in this
project. Explain Why should we do it?
What troubles would it cause if I
don't. Anything more you'd like to
mention? I mean regarding similar
errors. I'm very interested in Linker
& its problems. So, if there are any
similar things you can mentions them
or some keywords atleast.
MFC applications and the MFC library have to use the same memory management functions, so that memory allocated by MFC can be freed by the application and vice-versa. FILE handles and other resources are also shared. The MFC DLLs are already compiled to use the CRT in a DLL, and in order to be able to share resources you need to use the same CRT, which means using a DLL too.
You need to configure project properties so that your debug build links with DCMTK's debug build and your release build links with DCMTK's release build.
The above is what you need to do. Below are explanations of some other random things you asked about.
Older versions of Visual Studio used to have single threaded libraries (release and debug versions) besides multithreaded libraries (release and debug versions). For your project you can pretend single threaded libraries never existed.
If you experiment with random ways to trick the linker into shutting up and leaving problems to be found by your customers instead of by yourself, you might find that the /NODEFAULTLIB option will do that. The makers of the DCMTK library are warning you not to do that because some other people did the same dumb thing in the past.
Whats up with the "Debug Mode" (Multi-Threaded Debug) and "Release Mode" (Multi-Threaded)? What exactly is happening under the hood? Why exactly this thing is causing linking error?
They are different versions of the C runtime library. You can statically link to the runtime library in debug and release mode. In the Code Generation Options (mentioned below), those would be "Multi-Threaded Debug" and "Multi-Threaded". The options "Multi-Threaded Debug DLL" and "Multi-Threaded DLL" dynamically link to the C runtime. By dynamically linking to the runtime, you'll also have to ship your installer configured to install the VC redistributable package that contains the proper runtime dlls for your version of Visual C++.
Statically linking to the C runtime is generally frowned upon, even by Microsoft:
In addition to all the methods
described above of distributing the
Visual C++ libraries DLLs, there is
one last option for building your
application which does not require you
to distribute the DLLs. However, this
option only works for native-only code
(it is not supported with /clr) and
leaves your customers seriously
vulnerable to any security holes as
well as adds a significant burden upon
yourself to patch all customer systems
should a vulnerability be found in any
of the libraries. This option is to
statically link in the libraries as
.lib files instead of dynamically
loading them as DLLs. You do this by
using the /MT flag on the cl.exe
command line (vs /MD), or selecting
the appropriate option in your project
properties through Visual Studio. You
may wish to use this option when
testing early debug builds of your
application on test machines before
you start working on setup. [See
footnote 3]
However, I can think of no scenarios
in which this is actually the right
thing to do when shipping your product
to customers. Basically, what this
approach does is pulls in the binary
code needed from .LIB files at compile
time, making it a part of your .exe or
.dll files. It increases the size of
your application, and there is no way
to update the libraries apart from
recompiling your application with new
.LIBs and redistributing your
application all over again. What this
means is that unless you go touch
every single machine which has
installed your application every time
there is a security vulnerability
found in the Visual C++ libraries and
completely reinstall your updated
binaries, you will be leaving your
customers vulnerable to attack. If
instead you use the DLLs, every time
there is a security vulnerability
found in the Visual C++ libraries,
Microsoft will install the update
centrally into the WinSxS folder via
Windows Update and all requests for
the DLLs will be redirected to the
updated version. This removes all
servicing burden on your side and also
allows the user to install one small
update which will touch all their
applications instead of replacing
every installed exe and DLL on their
system. Please, do not distribute an
application built by linking
statically against the Visual C++
libraries unless you have a system in
place for updating every customer
machine and also have a very good
reason to do so. At this time, I can
think of no circumstance under which
this would be the right thing to do
for a shipping application.
I wonder if there is something called
"Single-Threaded Debug" and
"Single-Threaded" which again causes
the same thing.
No such thing, see above.
Documentation talks something about "Code Generation Options". What Code Generation Options? WTH are they?
Right click on your Visual C++ project (from within Visual Studio) and select Properties. Under Configuration Properties->C/C++->Code Generation
Documentation specifically warns us not to use /NODEFAULTLIB workaround. (example /NODEFAULTLIB :msvcrt ). Why? How would I cause troubles? what exactly is it?
Take their advice and don't do it.
Please explain the last point in the documentation for MFC users. Because I'm going to use MFC later in this project. Explain Why should we do it? What troubles would it cause if I don't.
Because MFC is dynamically linked to the C runtime, using libraries that are statically linked to the C runtime will cause the linker errors you listed first in your post.
Anything more you'd like to mention? I mean regarding similar errors. I'm very interested in Linker & its problems. So, if there are any similar things you can mentions them or some keywords atleast.
From my experience, always dynamically link to the C runtime. It generally saves you a lot of headaches like the one you're experiencing right now.
After going through a lengthy process to rename a project, my DLL project will not build in Debug mode (Release builds work):
MSVCRTD.lib(msvcr90d.dll) : error LNK2005: _CrtDbgReportW already defined in LIBCMTD.lib(dbgrpt.obj)
This project, and the five static libraries it depends on, are set to use "Multi-threaded Debug (/MTd)" (under C/C++|Code Generation|Runtime Library). I believe LIBCMTD.lib is the one for multi-threaded debug, but what is MSVCRTD.lib, and what could be causing this error?
If it makes a difference, this DLL is for Windows CE.
LIBCMT is what you need for /MT, MSVCRT is what you need for /MD. You are linking .obj and .lib files that were mixed, some compiled with /MT some with /MD. That's not good.
Usually it is the .lib files that cause the problem. Review their build settings and make sure their /M option is the same as your DLL project.
Also, beware of the trouble you can get into if the DLL was compiled with /MT. You'll have major problems when the DLL returns pointers to objects that the client needs to release. It can't, it doesn't use the same memory allocator.
The MSDN article on LNK4098 has a very useful table: it tells you which libraries to manually add to the "Ignore specific library" list, depending on which CRT you're using. In your case, you should ignore all of these:
libc.lib, libcmt.lib, msvcrt.lib, libcd.lib, libcmtd.lib
Observe that the reported library is in this list too. The problem is described in more detail in KB154753 ... libraries that a program will link with when built by using Visual C++
My interpretation of this is that in certain situations the algorithm that automatically picks which CRT libraries to link your code with will pick several conflicting libraries.
What is release set too? Setting a DLL to multithreaded debug can cause problems if you allocate memory that something accesing the DLL tries to free (they will be allocated in different heaps, for example). Try setting multi-threaded debug DLL.
Your link problem probably arises because a library you are linking to is expecting multithreaded debug DLL so the linker tries to link both and your link fails ...
The problem is the msvcr90d.dll is not in the windows ce image. It must be deployed with the application. The msvcr90d.dll is located in $(VCInstallDir)/ce/bin/$(ARCHFAM).
http://stackoverflow.com/questions/15959877/windows-ce-6-0-and-runtime-link-to-debug-dll-mdd