[Reprint] about the shape of the--error lnk2005:xxx has been defined in the Msvcrtd.lib (MSVCR90D.dll)--The problem analysis to solve

Original: http://www.cnblogs.com/qinfengxiaoyue/archive/2013/02/01/2889668.html

Transferred from: http://hi.baidu.com/qinfengxiaoyue/item/ff262ccfb53b4c2ba0b50a89

Citation: http://blog.csdn.net/sptoor/archive/2011/02/23/6203376.aspx

There are changes to the full text.

tip : Before reading, you need to know the difference between a static library (. Lib), a dynamic library (. dll), an import library (this or. lib). It is recommended to read Mr. Song Baohua's "VC + + dynamic link library (DLL) programming in layman"

keywords : library, CRT, LIBCMTD.lib, MSVCRTD.lib, link library conflict problem, MSVC link processing

1. The problem arises

For a long time did not write the introduction of programming knowledge related articles, this article to talk about the library link, as well as the MSVC and the CRT between the various

Revenge.

If you are using an operating system that is Linux, MAC, or other non-Windows platforms, you can ignore this post, if you are using an operating system that is

Windows platform, but without writing C + + programs with Microsoft Visual Studio C + + (hereinafter referred to as MSVC) software, this article

Help may be limited, but if your operating system is Windows and you are using a program that integrates your development environment with MSVC software to compose C + + programs, this

Article should help you to clarify some important basic ideas.

As a program designer, in the process of learning programming, have you ever encountered certain error messages that seem to be unintelligible, but do not know how to solve them? For example, when you

Happily finish the program, and confirm that all the program code can be successfully compiled, then execute the "Build Solution" (Build solution) step

, the result is a bunch of inexplicable errors:

1>libcmtd.lib (errmode.obj): Error LNK2005: ___set_app_type has been defined in Msvcrtd.lib (MSVCR90D.dll)

1>libcmtd.lib (dbgrptw.obj): Error LNK2005: __crtdbgreport has been defined in Msvcrtd.lib (MSVCR90D.dll)

1>msvcrtd.lib (MSVCR90D.dll): Error LNK2005: __SETMBCP has been defined in LIBCMTD.lib (mbctype.obj)

1>link:warning LNK4098: Default Library "Msvcrtd.lib" conflicts with other libraries; use/nodefaultlib:library

1>msvcrtd.lib (cinitexe.obj): Warning LNK4098: Default Library "LIBCMTD.lib" conflicts with the use of other libraries;

With/nodefaultlib:library

.....................

In general, it is easier to have a library of third-party libraries or open-source projects that are written by others in your program project.

The error condition described above. From these seemingly bizarre and confusing header thread error messages, we can probably guess that the problem lies in LIBCMTD.lib.

And MSVCRTD.lib these two libraries. But what exactly is LIBCMTD.lib and MSVCRTD.lib? These programs are used in our program code

Library?

The answer is yes.

2.C Runtime Library (C run-time libraries)

Programmers familiar with the C language know that if you want to use the basic I/O operations Functions of printf (), scanf () or fopen (), and so on, first

The stdio.h header file must be included in our program code using the #include syntax. By the functions of these I/O operation functions in Stdio.h

Declaration (Function declaration), the compiler (Compiler) was able to confirm that printf, scanf, and fopen, and so on, were legitimately available functions.

And when we write the program code after the compiler output in the form of OBJ file, we need to pass the linker (Linker) handler, the program code in all

There is a function definition link that is used to deliver the final program execution file. The question comes, and we know printf,

The function declarations of scanf and fopen exist in the stdio.h, but the function definitions of these guys, that is, the real definition program code, exactly what is stored in

What about the place?

In the standard library of the C language.

The standard program library, which is developed by C language, is called the "Execution Stage Library", which is the C Run-time library, which can be referred to as CRT generally. In C language

A common set of basic functions, such as I/O processing and string manipulation procedures, so long as we use C language to write programs

Code, must be compiled after the completion of the program code OBJ file, link to the C Language Execution stage library, to produce a legitimate C language program execution

Thing

The CRT is not only a single one by one version of the existence. In fact, apart from the use of "debug" and "release" for two different versions, the two can be

Derivation of the "Static link" and "Dynamic Link" two forms:

Static links :

LIBCMTD.lib (Debug version)

LIBCMT.lib

Dynamic Links :

MSVCRTD.lib (Debug version)

MSVCRT.lib

Although the use of these four CRT versions differs from the way they are used, there is a common feature that they are all designed to meet thread safety requirements and can be implemented in multiple execution lines

The library version that is used safely in the program code. In fact, in the previous version of MSVC 6, there were two additional LIBCD.lib (Debug versions) and

The LIBC.lib Library is a CRT version that is dedicated to single-threaded programs, but these two options have been removed from the settings option since MSVC 2005

, so most programmers now use a CRT version of multi-threaded execution.

In the behavior of library links (library linking), the difference between static and dynamic links is that when using static links, the function definitions of the library are embedded directly

In the execution file, while using dynamic linking, the library function definition exists in a separate file, usually a DLL-formatted file, and then

The line files are published together with the user. Therefore, in the size of the file, using a dynamically linked executable file is usually smaller than using a statically linked executable file file.

A few.

The benefit of using the dynamically linked CRT version is the ability to separate the standard libraries that are used frequently, and put them in the Windows system folder to reduce my

The size of the executable file file that was generated. In turn, however, the disadvantage of using the dynamic-link CRT version is the DLL files that are associated with executing files

On For example, if the program generates an execution file with the Debug state in MSVC 2005, the execution file needs to have a msvcr80d.dll presence in order to successfully

If it is a Release state, it is dependent on msvcr80.dll. But if you take the same program code to get MSVC 2008 generated, the resulting execution

The file is dependent on the Msvcr90d.dll and msvcr90.dll two different DLL files. Different versions of MSVC, will have their own different dependent DLL text

Thing

In the MSVC program project, how do you specify the program code to use a static link or a dynamically linked CRT version? It's actually very easy, just in the project properties

"c/c++" page, select the "Code Generation" sub-page, which has an "Execution Stage library" (Runtime Library)

Project, which is where the CRT link version is set in the project. There are a total of four options, which correspond to the above static link and dynamic link four different

The library version.

Multi-thread debugging (/MTD): Correspondence LIBCMTD.lib

Multi-Thread Execution (/MT): Correspondence LIBCMT.lib

multi-threaded debug DLLs (/MDD): Correspondence MSVCRTD.lib

Multi-thread DLL (/MD): Correspondence MSVCRT.lib

If you start generating a program without making any settings, the MSVC preset option will use the dynamically linked version.

3.Standard C + + library (standard C + + libraries)

Note that these are simply C-language libraries and do not include the C + + language. If your program system has code that contains the C + + language,

, that's another thing. but in the project Properties page, why can't I find the relevant setting options? Because MSVC quietly helped the programmer to do it.

Disposed of. As long as you use #include syntax in your program code to include any one C + + header file, such as iostream or FSTREAM,MSVC,

will automatically help us to link the C + + execution stage library during the operation of the linker. The C + + implementation Phase Library can also be divided into four versions:

Static links :

LIBCPMTD.lib (Debug version)

LIBCPMT.lib

Dynamic Links:

MSVCPRTD.lib (Debug Version): Execution file dependent on MSVCP90D.dll

MSVCPRT.lib: Execution file dependent on MSVCP90.dll

as far as the program execution file is using static or dynamically linked versions, it relies on the C language version setting option . As an example, if you write a

A Debug-configured C + + program that retains the original preset build option (dynamic link) of the project, the resulting program execution file will be

According to MSVCR90D.dll and MSVCP90D.dll two DLL files. If the same program is generated with the Release configuration, it will be dependent on the

MSVCR90.dll and MSVCP90.dll.

4. Problem analysis and resolution

Beginners who have just learned to program a program often find it impossible to start a process on someone else's computer when they complete a piece of work with joy and pass it on to others.

The user's computer is missing a DLL file and cannot execute the program's dilemma. There are three ways to solve this troubling problem:

1. User's computer, you must first install the "visual C + + Development Kit (MSVC 2008 or MSVC 2005).

2. Attach the required DLL files, such as MSVCR90D.dll and MSVCP90.dll, directly to the program's download package.

3. Generates a program execution file statically linked.

When you are unsure of your program or someone else's program, whether it is dependent on certain DLL files, there is a very handy free utility program Dependency

Walker, you can open the EXE format of the executable file or DLL format of the dynamic library, and then in detail to list their dependent DLL files.

After understanding several different CRT version options, back to the top error message question, I believe you should now be able to clearly understand that the original will occur these odd

the wrong situation is because the program also links LIBCMTD.lib and MSVCRTD.lib to create a function definition version conflict . in other words, the program linker has

The required function definition was found in one of the CRT versions, but now it jumps out of another CRT and gives an implementation version of the same function, so the link

The device cannot determine who should be ignored and who chooses.

The reason for this situation is that your program and program are linked to the external library, using a different version of the CRT. For example, when your program uses the

Lua, naturally, must link to Lua's library lua5.1.lib, but if Lua5.1.lib is generated as a statically linked version of the CRT, your program is based on a pre-

Set the option to dynamically link the CRT to generate the program execution file, this will produce these error messages. At this point, the answer to the question has been

decision There are two types of methods :

One is to re-create a new library in the form of dynamically linked CRT;

The second is to change your program project to a static link CRT mode generation.

In other words, when you are a design developer of a library, you want to share what you write to others, but you don't want to completely open up the source of your own writing program.

The following four versions of the library are available at the same time to properly meet the diverse needs of the user:

Debug: Dynamic Link Debug version

Release: Dynamic Link version

Debug_static: Static link Debug version

Release_static: Statically linked version

However, sometimes the world does not work so well. In some special situations, when we use third-party libraries written by others, we may sometimes only get

When one of these specific versions, such as the release_static version, is likely to encounter a library conflict error condition. At this point, you need to see the actual needs of the project

Instead, you can specify the option "Ignore specific libraries" (Ignore specific library) in the project properties, so that the program code linker ignores certain sequence libraries,

To resolve the conflict between the movement of the library or the old and new library.

Quiz: You write a program that must link to a library that is generated from a static multi-thread (/MT) CRT. If your program is in the Debug configuration,

The multi-thread debug (/MTD) option is generated, does it create a conflict? If your program is generated under the release configuration with the multiple threads (/MT) option,

Will conflict? If so, how should it be solved?

The above method is still not working! There will be other problems.

Here are some of the latest solutions I've explored:

First, all LIB files are compiled with/MTD or/MT (note: static link mode). Debug Debug mode uses/mtd,release mode with/MT.

You can then use/MTD or/MT to compile in your own program. This will not be a problem.

Three ways to compile a linked library:

(1) Connect to the Windows library. For applications written for the Win32 API, the above approach may introduce new problems, and you can ignore the LIBCMT.lib library. If you still

There are other issues, and then ignore the corresponding libraries.

(2) MFC static link. The method above is for this type of link, so no problem.

(3) MFC dynamic Link. Have not tried, should and (1) similar.

Finally add: If not yet, add/force:multiple compile parameters directly. This time it was not used, but also for the sake of rigor.

[Reprint] about the shape of the--error lnk2005:xxx has been defined in the Msvcrtd.lib (MSVCR90D.dll)--The problem analysis to solve