MSVC and the CRT's Revenge

It's been a long time since I wrote a program to design a related article about knowledge, this article will talk about the library link and the MSVC and the CRT between the various kinds of hatred.

If you are using an operating system that is Linux, MAC, or other non-Windows platforms, you can ignore this article; If you are using an operating system that is a Windows platform, it is not useful for Microsoft Visual Studio C + + (hereinafter referred to as MSVC) software to write c+ + program, this article may be of limited help to you, but if your operating system is Windows and you are using a program integration environment that is written by MSVC software C + +, this article should help you to clarify some important foundational observations as well.

As a programmer, in the process of learning programming, have you ever encountered some misleading messages that are unintelligible to you, and how do you know how to solve them? For example, when you are quick to write the program and make sure that all the code has been successfully translated, and then perform the steps of the build solution, the result is a bunch of inexplicable mistakes:--

LIBCMTD.lib (mlock.obj): Error LNK2005: __lock has been defined in MSVCRTD.lib (MSVCR80D.dll)
LIBCMTD.lib (mlock.obj): Error LNK2005: __unlock has been defined in MSVCRTD.lib (MSVCR80D.dll)
LIBCMTD.lib (crt0.obj): Error LNK2005: _maincrtstartup has been defined in MSVCRTD.lib (crtexe.obj)

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

Link:warning LNK4098: Preset library ' MSVCRTD ' with other use of the program, please use/nodefaultlib:library
Link:warning LNK4098: Preset library ' LIBCMTD ' with other use of the program, please use/nodefaultlib:library
D:\workspace\crtlibtest\debug\crtlibtest.exe:fatal Error LNK1169: Find one or more defined symbols

In general, if you have a program in your program that uses certain third-party or source-based repositories, it is easier to make the above-mentioned bug case. From these seemingly bizarre and confusing messages, we can probably guess that the problem should be in the LIBCMTD.lib and MSVCRTD.lib repositories as a result of the above. But what is LIBCMTD.lib and MSVCRTD.lib? Are these libraries used in our code?

The answer is yes.

Programmers familiar with C language know that if you want to use basic I/O operation functions like printf (), scanf () or fopen (), and so on, you first have to use the #include language method to get the stdio.h into our code. With the function declaration of these I/O operation functions in Stdio.h, the translator (Compiler) is able to confirm that printf, scanf, and fopen are all valid functions.

And when we write the code after the editor produces the file in OBJ form, it needs to be Linker by the processor, and the function definition of all the functions in the code will be built up to produce the final program of the file. "."------ The problem is, we know that printf, scanf, and fopen's function declarations exist in the stdio.h, but what is the meaning of these guys ' functions, the real code, exactly where they are stored?

In the standard library of C language.

The standard library, which is made from C, is called the "run- Stage Program Library", which is the C- run-time Library, which is commonly referred to as the CRT. In the standard library of C language, contains a group of commonly used basic functions, such as I/O process and string manipulation procedures and so on, so long as we use C language to write code, we must compile the finished code OBJ file, linked to the C language of the executive stage of the library, in order to produce a legitimate C language program to perform the file 。

And the CRT is not only a single one by one version exists. In fact, in addition to the "de-fault" and "release" The use of two versions, the two can be divided into separate "static link" and "Dynamic Link" two forms:

Static Links:

• LIBCMTD.lib (except for the wrong version)
• LIBCMT.lib

Dynamic Links:

• MSVCRTD.lib (except for the wrong version)
• MSVCRT.lib

While the four CRT versions are used in different ways, there is a common denominator that they are full of security requirements that can be safely used in multi-threading code in a repository version of the application. In fact, in the previous version of MSVC 6, there are two other LIBCD.lib (except the wrong version) and the LIBC.lib library, which is the CRT version used by the single-threading program, but these two options have been removed from the setup option since MSVC 2005, so now most Programmers use a multi-threading CRT version.

In the linking of the library, the difference between static and dynamic connections is that, when you use a static connection, the functions of the library are embedded directly into the script, and when you use the dynamic link, the function of the library exists in another independent file, usually a DLL Format files, and then release the user with the program's files. Therefore, in the case of file size, the use of the dynamic connection of the files, usually more than the use of the static connection of the operation of the file is smaller.

Using the dynamic version of the CRT is a good place to use the standard libraries that are used to stand alone and put them in the Windows system folder to reduce the size of the files we've built to perform the file. However, the lack of the use of the dynamic version of the CRT is also the case with the DLL files that are dependent on the file . For example, if the program builds Debug configurations with MSVC 2005, the file needs to have a msvcr80d.dll presence in order to perform the work, and if it is the Release group, it is dependent on msvcr80.dll. But if you take the same code to the MSVC 2008 build, the generated files are dependent on the Msvcr90d.dll and msvcr90.dll two different DLL files. different versions of MSVC will have their own different dependent DLL files.

In the MSVC program, how do you specify the version of the code that you want to use for static or dynamic connections? In fact, it is easy to select the "Code Generation" page in the "c/c++" page of the project, where there is a "Runtime library" item, which is where the CRT-linked version is used in the case of the project in the program. There are a total of four options, which are exactly the four different versions of the program that are linked to the above form.

• Multi-Threading (/MTD): LIBCMTD.lib
• Multi-Threading (/MT): LIBCMT.lib
• Multi-Threading Bug DLL (/MDD): MSVCRTD.lib
• Multi-Threading DLL (/MD): MSVCRT.lib

If you start building a program without making any assumptions, the MSVC preset will use the version of the verb.

C Runtime Library

Note that these are simply C-language repositories and do not contain C + + language. If your programming system has code that contains C + + language, that's another matter. But why can't we find a relevant set of options in the case of the specialized pages? because MSVC quietly helped the programmer to get rid of it. as long as you use #include language in your code to get into any of the C + + 's targets, such as iostream or FSTREAM,MSVC, you can automatically help us connect to the C + + run-time library in the connector's stage. and the C + + executive stage of the library, the same can be divided into four versions:

Static Links:

• LIBCPMTD.lib (except for the wrong version)
• LIBCPMT.lib

Dynamic Links:

• MSVCPRTD.lib (in addition to the wrong version): The MSVCP90D.dll is dependent on the file.
• MSVCPRT.lib: The MSVCP90.dll is dependent on the file.

As the program's version of a static or dynamic connection is used, it is dependent on the version of the C language. For example, if you write a C + + program with Debug, and keep the built-in option (the dynamic link) that was originally intended for the project, then the final program will be dependent on the MSVCR90D.dll and MSVCP90D.dll two DLL files. If the same program is built with Release, it will be dependent on both MSVCR90.dll and MSVCP90.dll.

Standard C + + Library

The person who has just studied the program design often finds it impossible to launch a program on someone's computer when it is done in a very happy way and communicates to others, and is stuck in a user's computer's lack of a DLL file without a travel-style dilemma. There are three ways to solve this annoying problem:

1. User's computer, you must first install the "visual C + + transferable Kit" (MSVC 2008 or MSVC 2005).
2. The required DLL files, such as MSVCR90D.dll and MSVCP90D.dll, are attached directly to the program's download package.
3. Build your program in a static manner.

When you can't make sure your program or someone else's program is dependent on some particular DLL file, there is a very good free utility Dependency Walker, which can open the EXE format of the script or DLL format, and then list the DLLs they are dependent on. Files.

After understanding a few different CRT versions, go back to the front of the wrong message, and I'm sure you can clearly understand that this is the odd bug that will happen because the program is connected to LIBCMTD.lib and MSVCRTD.lib, too. So it causes the definition version of the function to conflict. In other words, the program connector has found the required function definition in one of the CRT versions, but then it jumps out of the other CRT and gives a version of the same function, so the connector cannot judge who should be ignored and who chooses it.

The reason for this situation is that the external repositories that your programs and programs connect to use different versions of the CRT. For example, when your program uses LUA, you naturally have to connect to the LUA repository Lua5.1.lib, but if Lua5.1.lib is built with a static version of the CRT, and your program is programmed with a preset, and the CRT is used to build the program, This will give you these wrong messages. So far, the answer to the question is clear, there are two ways to solve the problem: one is to set up a new library in the way that Lua re-connects the CRT, and the other is to change its program to be built in a static, CRT way.

In other terms, when you're a designer for a library that wants to share what you've written with others, but doesn't want to fully open up your own programmed source code, at least at the same time, you can provide the following four versions of the library to properly meet the diverse needs of the user:

• Debug: Dynamic connection except the wrong version
• Release: Version of the motion
• Debug_static: Silent connection to the wrong version
• Release_static: Silent Version

However, sometimes the world does not work so well. In some special circumstances, when we use the third formula that others write, it is possible to get a specific version of it, such as the release_static version, and it is very likely to encounter the bug of the library conflict. This will require the actual needs of the project, you can specify in the project "ignore the Specific library" (Ignore specific Library) This option, let the code connector ignore some of the library, so as to resolve the conflict between the dynamic library or the new library.

Small test: The program that you write must be connected to a program that is built from a static multi-/MT CRT. If your program is built with the multi-/mtd option in Debug mode, will it produce conflicts? If your program is built with the multi-threading (/MT) option in Release, will it produce conflicts? Yes, how should we resolve it?

Extended reading:

• [MSDN] Visual Studio 2008:c run-time Libraries
• dynamically linking with MSVCRT. DLL using Visual C + + 2005

Transferred from: HTTP://BLOG.MONKEYPOTION.NET/GAMEPROG/BEGINNER/LOVE-AND-HATE-BETWEEN-MSVC-AND-CRT

MSVC and the CRT's Revenge