c/c++ 运行库
11.2? C/C++運(yùn)行庫(kù)
11.2.1? C語(yǔ)言運(yùn)行庫(kù)
任何一個(gè)C程序，它的背后都有一套龐大的代碼來(lái)進(jìn)行支撐，以使得該程序能夠正常運(yùn)行。這套代碼至少包括入口函數(shù)，及其所依賴的函數(shù)所構(gòu)成的函數(shù)集合。當(dāng)然，它還理應(yīng)包括各種標(biāo)準(zhǔn)庫(kù)函數(shù)的實(shí)現(xiàn)。
這樣的一個(gè)代碼集合稱之為運(yùn)行庫(kù)（RuntimeLibrary）。而C語(yǔ)言的運(yùn)行庫(kù)，即被稱為C運(yùn)行庫(kù)（CRT）。
如果讀者擁有VisualStudio，可以在VC/crt/src里找到一份C語(yǔ)言運(yùn)行庫(kù)的源代碼。然而，由于此源代碼過(guò)于龐大，僅僅.c文件就有近千個(gè)，并且和C++的STL代碼一起毫無(wú)組織地堆放在一起，以至于實(shí)際上沒(méi)有什么仔細(xì)閱讀的可能性。同樣，Linux下的libc源代碼讀起來(lái)也如同啃磚頭。所幸的是，在本章的最后，我們會(huì)一起來(lái)實(shí)現(xiàn)一個(gè)簡(jiǎn)單的運(yùn)行庫(kù)，讓大家更直觀地了解它。
一個(gè)C語(yǔ)言運(yùn)行庫(kù)大致包含了如下功能：
l??????????啟動(dòng)與退出：包括入口函數(shù)及入口函數(shù)所依賴的其他函數(shù)等。
l??????????標(biāo)準(zhǔn)函數(shù)：由C語(yǔ)言標(biāo)準(zhǔn)規(guī)定的C語(yǔ)言標(biāo)準(zhǔn)庫(kù)所擁有的函數(shù)實(shí)現(xiàn)。
l??????????I/O：I/O功能的封裝和實(shí)現(xiàn)，參見(jiàn)上一節(jié)中I/O初始化部分。
l??????????堆：堆的封裝和實(shí)現(xiàn)，參見(jiàn)上一節(jié)中堆初始化部分。
l??????????語(yǔ)言實(shí)現(xiàn)：語(yǔ)言中一些特殊功能的實(shí)現(xiàn)。
l??????????調(diào)試：實(shí)現(xiàn)調(diào)試功能的代碼。
在這些運(yùn)行庫(kù)的組成成分中，C語(yǔ)言標(biāo)準(zhǔn)庫(kù)占據(jù)了主要地位并且大有來(lái)頭。C語(yǔ)言標(biāo)準(zhǔn)庫(kù)是C語(yǔ)言標(biāo)準(zhǔn)化的基礎(chǔ)函數(shù)庫(kù)，我們平時(shí)使用的printf、exit等都是標(biāo)準(zhǔn)庫(kù)中的一部分。標(biāo)準(zhǔn)庫(kù)定義了C語(yǔ)言中普遍存在的函數(shù)集合，我們可以放心地使用標(biāo)準(zhǔn)庫(kù)中規(guī)定的函數(shù)而不用擔(dān)心在將代碼移植到別的平臺(tái)時(shí)對(duì)應(yīng)的平臺(tái)上不提供這個(gè)函數(shù)。在下一章節(jié)里，我們會(huì)介紹C語(yǔ)言標(biāo)準(zhǔn)庫(kù)的函數(shù)集合，并對(duì)一些特殊的函數(shù)集合進(jìn)行詳細(xì)介紹。
標(biāo)準(zhǔn)庫(kù)的歷史
在計(jì)算機(jī)世界的歷史中，C語(yǔ)言在AT&T的貝爾實(shí)驗(yàn)室誕生了。初生的C語(yǔ)言在功能上非常不完善，例如不提供I/O相關(guān)的函數(shù)。因此在C語(yǔ)言的發(fā)展過(guò)程中，C語(yǔ)言社區(qū)共同意識(shí)到建立一個(gè)基礎(chǔ)函數(shù)庫(kù)的必要性。與此同時(shí)，在20世紀(jì)70年代C語(yǔ)言變得非常流行時(shí)，許多大學(xué)、公司和組織都自發(fā)地編寫自己的C語(yǔ)言變種和基礎(chǔ)函數(shù)庫(kù)，因此當(dāng)?shù)搅?0年代時(shí)，C語(yǔ)言已經(jīng)出現(xiàn)了大量的變種和多種不同的基礎(chǔ)函數(shù)庫(kù)，這對(duì)代碼遷移等方面造成了巨大的障礙，許多大學(xué)、公司和組織在共享代碼時(shí)為了將代碼在不同的C語(yǔ)言變種之間移植搞得焦頭爛額，怨聲載道。于是對(duì)此慘狀忍無(wú)可忍的美國(guó)國(guó)家標(biāo)準(zhǔn)協(xié)會(huì)（American National Standards Institute,ANSI）在1983年成立了一個(gè)委員會(huì)，旨在對(duì)C語(yǔ)言進(jìn)行標(biāo)準(zhǔn)化，此委員會(huì)所建立的C語(yǔ)言標(biāo)準(zhǔn)被稱為ANSIC。第一個(gè)完整的C語(yǔ)言標(biāo)準(zhǔn)建立于1989年，此版本的C語(yǔ)言標(biāo)準(zhǔn)稱為C89。在C89標(biāo)準(zhǔn)中，包含了C語(yǔ)言基礎(chǔ)函數(shù)庫(kù)，由C89指定的C語(yǔ)言基礎(chǔ)函數(shù)庫(kù)就稱為ANSI C標(biāo)準(zhǔn)運(yùn)行庫(kù)（簡(jiǎn)稱標(biāo)準(zhǔn)庫(kù)）。其后在1995年C語(yǔ)言標(biāo)準(zhǔn)委員會(huì)對(duì)C89標(biāo)準(zhǔn)進(jìn)行了一次修訂，在此次修訂中，ANSIC標(biāo)準(zhǔn)庫(kù)得到了第一次擴(kuò)充，頭文件iso646.h、wchar.h和wctype.h加入了標(biāo)準(zhǔn)庫(kù)的大家庭。在1999年，C99標(biāo)準(zhǔn)誕生，C語(yǔ)言標(biāo)準(zhǔn)庫(kù)得到了進(jìn)一步的擴(kuò)充，頭文件complex.h、fenv.h、inttypes.h、stdbool.h、stdint.h和tgmath.h進(jìn)入標(biāo)準(zhǔn)庫(kù)。自此，C語(yǔ)言標(biāo)準(zhǔn)庫(kù)的面貌一直延續(xù)至今。
11.2.2? C語(yǔ)言標(biāo)準(zhǔn)庫(kù)
在本章節(jié)里，我們將介紹C語(yǔ)言標(biāo)準(zhǔn)庫(kù)的基本函數(shù)集合，并對(duì)其中一些特殊函數(shù)進(jìn)行詳細(xì)的介紹。ANSIC的標(biāo)準(zhǔn)庫(kù)由24個(gè)C頭文件組成。與許多其他語(yǔ)言（如Java）的標(biāo)準(zhǔn)庫(kù)不同，C語(yǔ)言的標(biāo)準(zhǔn)庫(kù)非常輕量，它僅僅包含了數(shù)學(xué)函數(shù)、字符/字符串處理，I/O等基本方面，例如：
l??????????標(biāo)準(zhǔn)輸入輸出（stdio.h）。
l??????????文件操作（stdio.h）。
l??????????字符操作（ctype.h）。
l??????????字符串操作（string.h）。
l??????????數(shù)學(xué)函數(shù)（math.h）。
l??????????資源管理（stdlib.h）。
l??????????格式轉(zhuǎn)換（stdlib.h）。
l??????????時(shí)間/日期（time.h）。
l??????????斷言（assert.h）。
l??????????各種類型上的常數(shù)（limits.h & float.h）。
除此之外，C語(yǔ)言標(biāo)準(zhǔn)庫(kù)還有一些特殊的庫(kù)，用于執(zhí)行一些特殊的操作，例如：
l??????????變長(zhǎng)參數(shù)（stdarg.h）。
l??????????非局部跳轉(zhuǎn)（setjmp.h）。
相信常見(jiàn)的C語(yǔ)言函數(shù)讀者們都已經(jīng)非常熟悉，因此這里就不再一一介紹，接下來(lái)讓我們看看兩組特殊函數(shù)的細(xì)節(jié)。
1. 變長(zhǎng)參數(shù)
變長(zhǎng)參數(shù)是C語(yǔ)言的特殊參數(shù)形式，例如如下函數(shù)聲明：
int printf(const char* format, ...);
如此的聲明表明，printf函數(shù)除了第一個(gè)參數(shù)類型為constchar*之外，其后可以追加任意數(shù)量、任意類型的參數(shù)。在函數(shù)的實(shí)現(xiàn)部分，可以使用stdarg.h里的多個(gè)宏來(lái)訪問(wèn)各個(gè)額外的參數(shù)：假設(shè)lastarg是變長(zhǎng)參數(shù)函數(shù)的最后一個(gè)具名參數(shù)（例如printf里的format），那么在函數(shù)內(nèi)部定義類型為va_list的變量：
va_list ap;
該變量以后將會(huì)依次指向各個(gè)可變參數(shù)。ap必須用宏va_start初始化一次，其中l(wèi)astarg必須是函數(shù)的最后一個(gè)具名的參數(shù)。
va_start(ap, lastarg);
此后，可以使用va_arg宏來(lái)獲得下一個(gè)不定參數(shù)（假設(shè)已知其類型為type）：
type next = va_arg(ap, type);
在函數(shù)結(jié)束前，還必須用宏va_end來(lái)清理現(xiàn)場(chǎng)。在這里我們可以討論這幾個(gè)宏的實(shí)現(xiàn)細(xì)節(jié)。在研究這幾個(gè)宏之前，我們要先了解變長(zhǎng)參數(shù)的實(shí)現(xiàn)原理。變長(zhǎng)參數(shù)的實(shí)現(xiàn)得益于C語(yǔ)言默認(rèn)的cdecl調(diào)用慣例的自右向左壓棧傳遞方式。設(shè)想如下的函數(shù)：
int sum(unsigned num, ...);
其語(yǔ)義如下：
第一個(gè)參數(shù)傳遞一個(gè)整數(shù)num，緊接著后面會(huì)傳遞num個(gè)整數(shù)，返回num個(gè)整數(shù)的和。
當(dāng)我們調(diào)用：
int n = sum(3, 16, 38, 53);
參數(shù)在棧上會(huì)形成如圖11-7所示的布局。
?
圖11-7?函數(shù)參數(shù)在棧上分布
在函數(shù)內(nèi)部，函數(shù)可以使用名稱num來(lái)訪問(wèn)數(shù)字3，但無(wú)法使用任何名稱訪問(wèn)其他的幾個(gè)不定參數(shù)。但此時(shí)由于棧上其他的幾個(gè)參數(shù)實(shí)際恰好依序排列在參數(shù)num的高地址方向，因此可以很簡(jiǎn)單地通過(guò)num的地址計(jì)算出其他參數(shù)的地址。sum函數(shù)的實(shí)現(xiàn)如下：
int sum(unsigned num, ...)
{
??? int* p =&num + 1;
??? int ret =0;
??? while(num--)
???????ret += *p++;
??? returnret;
}
在這里我們可以觀察到兩個(gè)事實(shí)：
（1）sum函數(shù)獲取參數(shù)的量?jī)H取決于num參數(shù)的值，因此，如果num參數(shù)的值不等于實(shí)際傳遞的不定參數(shù)的數(shù)量，那么sum函數(shù)可能取到錯(cuò)誤的或不足的參數(shù)。
（2）cdecl調(diào)用慣例保證了參數(shù)的正確清除。我們知道有些調(diào)用慣例（如stdcall）是由被調(diào)用方負(fù)責(zé)清除堆棧的參數(shù)，然而，被調(diào)用方在這里其實(shí)根本不知道有多少參數(shù)被傳遞進(jìn)來(lái)，所以沒(méi)有辦法清除堆棧。而cdecl恰好是調(diào)用方負(fù)責(zé)清除堆棧，因此沒(méi)有這個(gè)問(wèn)題。
printf的不定參數(shù)比sum要復(fù)雜得多，因?yàn)閜rintf的參數(shù)不僅數(shù)量不定，而且類型也不定。所以printf需要在格式字符串中注明參數(shù)的類型，例如用%d表明是一個(gè)整數(shù)。printf里的格式字符串如果將類型描述錯(cuò)誤，因?yàn)椴煌瑓?shù)的大小不同，不僅可能導(dǎo)致這個(gè)參數(shù)的輸出錯(cuò)誤，還有可能導(dǎo)致其后的一系列參數(shù)錯(cuò)誤。
【小實(shí)驗(yàn)】
printf的狂亂輸出
#include<stdio.h>
int main()
{
???printf("%lf/t%d/t%c/n", 1, 666, 'a');
}
在這個(gè)程序里，printf的第一個(gè)輸出參數(shù)是一個(gè)int（4字節(jié)），而我們告訴printf它是一個(gè)double（8字節(jié)以上），因此printf的輸出會(huì)錯(cuò)誤，由于printf在讀取double的時(shí)候?qū)嶋H造成了越界，因此后面幾個(gè)參數(shù)的輸出也會(huì)失敗。該程序的實(shí)際輸出為（根據(jù)實(shí)際編譯器和環(huán)境可能不同）：
0.000000????97? ?'
下面讓我們來(lái)看va_list等宏應(yīng)該如何實(shí)現(xiàn)。
va_list實(shí)際是一個(gè)指針，用來(lái)指向各個(gè)不定參數(shù)。由于類型不明，因此這個(gè)va_list以void*或char*為最佳選擇。
va_start將va_list定義的指針指向函數(shù)的最后一個(gè)參數(shù)后面的位置，這個(gè)位置就是第一個(gè)不定參數(shù)。
va_arg獲取當(dāng)前不定參數(shù)的值，并根據(jù)當(dāng)前不定參數(shù)的大小將指針移向下一個(gè)參數(shù)。
va_end將指針清0。
按照以上思路，va系列宏的一個(gè)最簡(jiǎn)單的實(shí)現(xiàn)就可以得到了，如下所示：
#define va_list char*
#define va_start(ap,arg)(ap=(va_list)&arg+sizeof(arg))
#define va_arg(ap,t)(*(t*)((ap+=sizeof(t))-sizeof(t)))
#define va_end(ap) (ap=(va_list)0)
【小提示】
變長(zhǎng)參數(shù)宏
在很多時(shí)候我們希望在定義宏的時(shí)候也能夠像print一樣可以使用變長(zhǎng)參數(shù)，即宏的參數(shù)可以是任意個(gè)，這個(gè)功能可以由編譯器的變長(zhǎng)參數(shù)宏實(shí)現(xiàn)。在GCC編譯器下，變長(zhǎng)參數(shù)宏可以使用“##”宏字符串連接操作實(shí)現(xiàn)，比如：
#define printf(args…) fprintf(stdout, ##args)
那么printf(“%d %s”, 123,“hello”)就會(huì)被展開(kāi)成：
fprintf(stdout, “%d %s”, 123, “hello”)
而在MSVC下，我們可以使用__VA_ARGS__這個(gè)編譯器內(nèi)置宏，比如：
#define printf(…) fprintf(stdout,__VA_ARGS__)
它的效果與前面的GCC下使用##的效果一樣。
2. 非局部跳轉(zhuǎn)
非局部跳轉(zhuǎn)即使在C語(yǔ)言里也是一個(gè)備受爭(zhēng)議的機(jī)制。使用非局部跳轉(zhuǎn)，可以實(shí)現(xiàn)從一個(gè)函數(shù)體內(nèi)向另一個(gè)事先登記過(guò)的函數(shù)體內(nèi)跳轉(zhuǎn)，而不用擔(dān)心堆棧混亂。下面讓我們來(lái)看一個(gè)示例：
#include<setjmp.h>
#include<stdio.h>
jmp_buf b;
void f()
{
??? longjmp(b,1);
}
int main()
{
??? if(setjmp(b))
???????printf("World!");
??? else
??? {
???????printf("Hello ");
???????f();
??? }
}
這段代碼按常理不論setjmp返回什么，也只會(huì)打印出“Hello ”和“World！”之一，然而事實(shí)上的輸出是：
Hello World!
實(shí)際上，當(dāng)setjmp正常返回的時(shí)候，會(huì)返回0，因此會(huì)打印出“Hello”的字樣。而longjmp的作用，就是讓程序的執(zhí)行流回到當(dāng)初setjmp返回的時(shí)刻，并且返回由longjmp指定的返回值（longjmp的參數(shù)2），也就是1，自然接著會(huì)打印出“World！”并退出。換句話說(shuō)，longjmp可以讓程序“時(shí)光倒流”回setjmp返回的時(shí)刻，并改變其行為，以至于改變了未來(lái)。
是的，這絕對(duì)不是結(jié)構(gòu)化編程。K
11.2.3? glibc與MSVC CRT
運(yùn)行庫(kù)是平臺(tái)相關(guān)的，因?yàn)樗c操作系統(tǒng)結(jié)合得非常緊密。C語(yǔ)言的運(yùn)行庫(kù)從某種程度上來(lái)講是C語(yǔ)言的程序和不同操作系統(tǒng)平臺(tái)之間的抽象層，它將不同的操作系統(tǒng)API抽象成相同的庫(kù)函數(shù)。比如我們可以在不同的操作系統(tǒng)平臺(tái)下使用fread來(lái)讀取文件，而事實(shí)上fread在不同的操作系統(tǒng)平臺(tái)下的實(shí)現(xiàn)是不同的，但作為運(yùn)行庫(kù)的使用者我們不需要關(guān)心這一點(diǎn)。雖然各個(gè)平臺(tái)下的C語(yǔ)言運(yùn)行庫(kù)提供了很多功能，但很多時(shí)候它們畢竟有限，比如用戶的權(quán)限控制、操作系統(tǒng)線程創(chuàng)建等都不是屬于標(biāo)準(zhǔn)的C語(yǔ)言運(yùn)行庫(kù)。于是我們不得不通過(guò)其他的辦法，諸如繞過(guò)C語(yǔ)言運(yùn)行庫(kù)直接調(diào)用操作系統(tǒng)API或使用其他的庫(kù)。Linux和Windows平臺(tái)下的兩個(gè)主要C語(yǔ)言運(yùn)行庫(kù)分別為glibc（GNU CLibrary）和MSVCRT（Microsoft Visual C Run-time），我們?cè)谙旅鎸?huì)分別介紹它們。
值得注意的是，像線程操作這樣的功能并不是標(biāo)準(zhǔn)的C語(yǔ)言運(yùn)行庫(kù)的一部分，但是glibc和MSVCRT都包含了線程操作的庫(kù)函數(shù)。比如glibc有一個(gè)可選的pthread庫(kù)中的pthread_create()函數(shù)可以用來(lái)創(chuàng)建線程；而MSVCRT中可以使用_beginthread()函數(shù)來(lái)創(chuàng)建線程。所以glibc和MSVCRT事實(shí)上是標(biāo)準(zhǔn)C語(yǔ)言運(yùn)行庫(kù)的超集，它們各自對(duì)C標(biāo)準(zhǔn)庫(kù)進(jìn)行了一些擴(kuò)展。
glibc
glibc即GNU C Library，是GNU旗下的C標(biāo)準(zhǔn)庫(kù)。最初由自由軟件基金會(huì)FSF（FreeSoftwareFoundation）發(fā)起開(kāi)發(fā)，目的是為GNU操作系統(tǒng)開(kāi)發(fā)一個(gè)C標(biāo)準(zhǔn)庫(kù)。GNU操作系統(tǒng)的最初計(jì)劃的內(nèi)核是Hurd，一個(gè)微內(nèi)核的構(gòu)架系統(tǒng)。Hurd因?yàn)榉N種原因開(kāi)發(fā)進(jìn)展緩慢，而Linux因?yàn)樗膶?shí)用性而逐漸風(fēng)靡，最后取代Hurd成了GNU操作系統(tǒng)的內(nèi)核。于是glibc從最初開(kāi)始支持Hurd到后來(lái)漸漸發(fā)展成同時(shí)支持Hurd和Linux，而且隨著Linux的越來(lái)越流行，glibc也主要關(guān)注Linux下的開(kāi)發(fā)，成為了Linux平臺(tái)的C標(biāo)準(zhǔn)庫(kù)。
20世紀(jì)90年代初，在glibc成為L(zhǎng)inux下的C運(yùn)行庫(kù)之前，Linux的開(kāi)發(fā)者們因?yàn)殚_(kāi)發(fā)的需要，從Linux內(nèi)核代碼里面分離出了一部分代碼，形成了早期Linux下的C運(yùn)行庫(kù)。這個(gè)C運(yùn)行庫(kù)又被稱為L(zhǎng)inuxlibc。這個(gè)版本的C運(yùn)行庫(kù)被維護(hù)了很多年，從版本2一直開(kāi)發(fā)到版本5。如果你去看早期版本的Linux，會(huì)發(fā)現(xiàn)/lib目錄下面有l(wèi)ibc.so.5這樣的文件，這個(gè)文件就是第五個(gè)版本的Linux libc。1996年FSF發(fā)布了glibc2.0，這個(gè)版本的glibc開(kāi)始支持諸多特性，比如它完全支持POSIX標(biāo)準(zhǔn)、國(guó)際化、IPv6、64-位數(shù)據(jù)訪問(wèn)、多線程及改進(jìn)了代碼的可移植性。在此時(shí)Linuxlibc的開(kāi)發(fā)者也認(rèn)識(shí)到單獨(dú)地維護(hù)一份Linux下專用的C運(yùn)行庫(kù)是沒(méi)有必要的，于是Linux開(kāi)始采用glibc作為默認(rèn)的C運(yùn)行庫(kù)，并且將2.x版本的glibc看作是Linuxlibc的后繼版本。于是我們可以看到，glibc在/lib目錄下的.so文件為libc.so.6，即第六個(gè)libc版本，而且在各個(gè)Linux發(fā)行版中，glibc往往被稱為libc6。glibc在Linux平臺(tái)下占據(jù)了主導(dǎo)地位之后，它又被移植到了其他操作系統(tǒng)和其他硬件平臺(tái)，諸如FreeBSD、NetBSD等，而且它支持?jǐn)?shù)十種CPU及嵌入式平臺(tái)。目前最新的glibc版本號(hào)是2.8（2008年4月）。
glibc的發(fā)布版本主要由兩部分組成，一部分是頭文件，比如stdio.h、stdlib.h等，它們往往位于/usr/include；另外一部分則是庫(kù)的二進(jìn)制文件部分。二進(jìn)制部分主要的就是C語(yǔ)言標(biāo)準(zhǔn)庫(kù)，它有靜態(tài)和動(dòng)態(tài)兩個(gè)版本。動(dòng)態(tài)的標(biāo)準(zhǔn)庫(kù)我們及在本書的前面章節(jié)中碰到過(guò)了，它位于/lib/libc.so.6；而靜態(tài)標(biāo)準(zhǔn)庫(kù)位于/usr/lib/libc.a。事實(shí)上glibc除了C標(biāo)準(zhǔn)庫(kù)之外，還有幾個(gè)輔助程序運(yùn)行的運(yùn)行庫(kù)，這幾個(gè)文件可以稱得上是真正的“運(yùn)行庫(kù)”。它們就是/usr/lib/crt1.o、/usr/lib/crti.o和/usr/lib/crtn.o。是不是對(duì)這幾個(gè)文件還有點(diǎn)印象呢？我們?cè)诘?章講到靜態(tài)庫(kù)鏈接的時(shí)候已經(jīng)碰到過(guò)它們了，雖然它們都很小，但這幾個(gè)文件都是程序運(yùn)行的最關(guān)鍵的文件。
glibc啟動(dòng)文件
crt1.o里面包含的就是程序的入口函數(shù)_start，由它負(fù)責(zé)調(diào)用__libc_start_main初始化libc并且調(diào)用main函數(shù)進(jìn)入真正的程序主體。實(shí)際上最初開(kāi)始的時(shí)候它并不叫做crt1.o，而是叫做crt.o，包含了基本的啟動(dòng)、退出代碼。由于當(dāng)時(shí)有些鏈接器對(duì)鏈接時(shí)目標(biāo)文件和庫(kù)的順序有依賴性，crt.o這個(gè)文件必須被放在鏈接器命令行中的所有輸入文件中的第一個(gè)，為了強(qiáng)調(diào)這一點(diǎn)，crt.o被更名為crt0.o，表示它是鏈接時(shí)輸入的第一個(gè)文件。
后來(lái)由于C++的出現(xiàn)和ELF文件的改進(jìn)，出現(xiàn)了必須在main()函數(shù)之前執(zhí)行的全局/靜態(tài)對(duì)象構(gòu)造和必須在main()函數(shù)之后執(zhí)行的全局/靜態(tài)對(duì)象析構(gòu)。為了滿足類似的需求，運(yùn)行庫(kù)在每個(gè)目標(biāo)文件中引入兩個(gè)與初始化相關(guān)的段“.init”和“.finit”。運(yùn)行庫(kù)會(huì)保證所有位于這兩個(gè)段中的代碼會(huì)先于/后于main()函數(shù)執(zhí)行，所以用它們來(lái)實(shí)現(xiàn)全局構(gòu)造和析構(gòu)就是很自然的事情了。鏈接器在進(jìn)行鏈接時(shí)，會(huì)把所有輸入目標(biāo)文件中的“.init”和“.finit”按照順序收集起來(lái)，然后將它們合并成輸出文件中的“.init”和“.finit”。但是這兩個(gè)輸出的段中所包含的指令還需要一些輔助的代碼來(lái)幫助它們啟動(dòng)（比如計(jì)算GOT之類的），于是引入了兩個(gè)目標(biāo)文件分別用來(lái)幫助實(shí)現(xiàn)初始化函數(shù)的crti.o和crtn.o。
與此同時(shí)，為了支持新的庫(kù)和可執(zhí)行文件格式，crt0.o也進(jìn)行了升級(jí)，變成了crt1.o。crt0.o和crt1.o之間的區(qū)別是crt0.o為原始的，不支持“.init”和“.finit”的啟動(dòng)代碼，而crt1.o是改進(jìn)過(guò)后，支持“.init”和“.finit”的版本。這一點(diǎn)我們從反匯編crt1.o可以看到，它向libc啟動(dòng)函數(shù)__libc_start_main()傳遞了兩個(gè)函數(shù)指針“__libc_csu_init”和“__libc_csu_fini”，這兩個(gè)函數(shù)負(fù)責(zé)調(diào)用_init()和_finit()，我們?cè)诤竺妗癈++全局構(gòu)造和析構(gòu)”的章節(jié)中還會(huì)詳細(xì)分析。
為了方便運(yùn)行庫(kù)調(diào)用，最終輸出文件中的“.init”和“.finit”兩個(gè)段實(shí)際上分別包含的是_init()和_finit()這兩個(gè)函數(shù)，我們?cè)陉P(guān)于運(yùn)行庫(kù)初始化的部分也會(huì)看到這兩個(gè)函數(shù)，并且在C++全局構(gòu)造和析構(gòu)的章節(jié)中也會(huì)分析它們是如何實(shí)現(xiàn)全局構(gòu)造和析構(gòu)的。crti.o和crtn.o這兩個(gè)目標(biāo)文件中包含的代碼實(shí)際上是_init()函數(shù)和_finit()函數(shù)的開(kāi)始和結(jié)尾部分，當(dāng)這兩個(gè)文件和其他目標(biāo)文件安裝順序鏈接起來(lái)以后，剛好形成兩個(gè)完整的函數(shù)_init()和_finit()。我們用objdump可以查看這兩個(gè)文件的反匯編代碼：
$ objdump -dr/usr/lib/crti.o
crti.o:????file format elf32-i386
Disassembly of section .init:
00000000 <_init>:
??0:??55?????????????????????push?? �p
??1:?? 89e5??????????????????mov???%esp,�p
??3:??53?????????????????????push?? �x
??4:?? 83 ec04???????????????sub???$0x4,%esp
??7:?? e8 00 00 0000?????????call?? c<_init+0xc>
??c:??5b?????????????????????pop??? �x
??d:?? 81 c3 03 00 0000??????add???$0x3,�x
???????????????????????f: R_386_GOTPC? _GLOBAL_OFFSET_TABLE_
?13:?? 8b 93 00 00 0000??????mov 0x0(�x),�x
???????????????????????15: R_386_GOT32 __gmon_start__
?19:?? 85d2??????????????????test?? �x,�x
?1b:?? 7405??????????????????je????22 <_init+0x22>
?1d:?? e8 fc ff ffff?????????call?? 1e<_init+0x1e>
???????????????????????1e: R_386_PLT32 __gmon_start__
Disassembly of section .fini:
00000000 <_fini>:
??0:??55?????????????????????push?? �p
??1:?? 89e5??????????????????mov???%esp,�p
??3:??53?????????????????????push?? �x
??4:?? 83 ec04???????????????sub???$0x4,%esp
??7:?? e8 00 00 0000?????????call?? c<_fini+0xc>
??c:??5b?????????????????????pop??? �x
??d:?? 81 c3 03 00 0000??????add???$0x3,�x
???????????????????????f: R_386_GOTPC? _GLOBAL_OFFSET_TABLE_
$ objdump -dr/usr/lib/crtn.o
crtn.o:????file format elf32-i386
Disassembly of section .init:
00000000 <.init>:
??0:??58?????????????????????pop??? �x
??1:??5b?????????????????????pop??? �x
??2:??c9?????????????????????leave
??3:??c3?????????????????????ret
Disassembly of section .fini:
00000000 <.fini>:
??0:??59?????????????????????pop??? �x
??1:??5b?????????????????????pop??? �x
??2:??c9?????????????????????leave
??3:??c3?????????????????????ret
于是在最終鏈接完成之后，輸出的目標(biāo)文件中的“.init”段只包含了一個(gè)函數(shù)_init()，這個(gè)函數(shù)的開(kāi)始部分來(lái)自于crti.o的“.init”段，結(jié)束部分來(lái)自于crtn.o的“.init”段。為了保證最終輸出文件中“.init”和“.finit”的正確性，我們必須保證在鏈接時(shí)，crti.o必須在用戶目標(biāo)文件和系統(tǒng)庫(kù)之前，而crtn.o必須在用戶目標(biāo)文件和系統(tǒng)庫(kù)之后。鏈接器的輸入文件順序一般是：
ld crt1.o crti.o [user_objects] [system_libraries]crtn.o
由于crt1.o（crt0.o）不包含“.init”段和“.finit”段，所以不會(huì)影響最終生成“.init”和“.finit”段時(shí)的順序。輸出文件中的“.init”段看上去應(yīng)該如圖11-8所示（對(duì)于“.finit”來(lái)說(shuō)也一樣）。
?
圖11-8?.init段的組成
在默認(rèn)情況下，ld鏈接器會(huì)將libc、crt1.o等這些CRT和啟動(dòng)文件與程序的模塊鏈接起來(lái)，但是有些時(shí)候，我們可能不需要這些文件，或者希望使用自己的libc和crt1.o等啟動(dòng)文件，以替代系統(tǒng)默認(rèn)的文件，這種情況在嵌入式系統(tǒng)或操作系統(tǒng)內(nèi)核編譯的時(shí)候很常見(jiàn)。GCC提高了兩個(gè)參數(shù)“-nostartfile”和“-nostdlib”，分別用來(lái)取消默認(rèn)的啟動(dòng)文件和C語(yǔ)言運(yùn)行庫(kù)。
其實(shí)C++全局對(duì)象的構(gòu)造函數(shù)和析構(gòu)函數(shù)并不是直接放在.init和.finit段里面的，而是把一個(gè)執(zhí)行所有構(gòu)造/析構(gòu)的函數(shù)的調(diào)用放在里面，由這個(gè)函數(shù)進(jìn)行真正的構(gòu)造和析構(gòu)，我們?cè)诤竺娴恼鹿?jié)還會(huì)再詳細(xì)分析ELF/Glib和PE/MSVC對(duì)全局對(duì)象構(gòu)造和析構(gòu)的過(guò)程。
除了全局對(duì)象構(gòu)造和析構(gòu)之外，.init和.finit還有其他的作用。由于它們的特殊性（在main之前/后執(zhí)行），一些用戶監(jiān)控程序性能、調(diào)試等工具經(jīng)常利用它們進(jìn)行一些初始化和反初始化的工作。當(dāng)然我們也可以使用“__attribute__((section(“.init”)))”將函數(shù)放到.init段里面，但是要注意的是普通函數(shù)放在“.init”是會(huì)破壞它們的結(jié)構(gòu)的，因?yàn)楹瘮?shù)的返回指令使得_init()函數(shù)會(huì)提前返回，必須使用匯編指令，不能讓編譯器產(chǎn)生“ret”指令。
GCC平臺(tái)相關(guān)目標(biāo)文件
就這樣，在第2章中我們?cè)阪溄訒r(shí)碰到過(guò)的諸多輸入文件中，已經(jīng)解決了crt1.o、crti.o和crtn.o，剩下的還有幾個(gè)crtbeginT.o、libgcc.a、libgcc_eh.a、crtend.o。嚴(yán)格來(lái)講，這幾個(gè)文件實(shí)際上不屬于glibc，它們是GCC的一部分，它們都位于GCC的安裝目錄下：
l??????????/usr/lib/gcc/i486-Linux-gnu/4.1.3/crtbeginT.o
l??????????/usr/lib/gcc/i486-Linux-gnu/4.1.3/libgcc.a
l??????????/usr/lib/gcc/i486-Linux-gnu/4.1.3/libgcc_eh.a
l??????????/usr/lib/gcc/i486-Linux-gnu/4.1.3/crtend.o
首先是crtbeginT.o及crtend.o，這兩個(gè)文件是真正用于實(shí)現(xiàn)C++全局構(gòu)造和析構(gòu)的目標(biāo)文件。那么為什么已經(jīng)有了crti.o和crtn.o之后，還需要這兩個(gè)文件呢？我們知道，C++這樣的語(yǔ)言的實(shí)現(xiàn)是跟編譯器密切相關(guān)的，而glibc只是一個(gè)C語(yǔ)言運(yùn)行庫(kù)，它對(duì)C++的實(shí)現(xiàn)并不了解。而GCC是C++的真正實(shí)現(xiàn)者，它對(duì)C++的全局構(gòu)造和析構(gòu)了如指掌。于是它提供了兩個(gè)目標(biāo)文件crtbeginT.o和crtend.o來(lái)配合glibc實(shí)現(xiàn)C++的全局構(gòu)造和析構(gòu)。事實(shí)上是crti.o和crtn.o中的“.init”和“.finit”提供一個(gè)在main()之前和之后運(yùn)行代碼的機(jī)制，而真正全局構(gòu)造和析構(gòu)則由crtbeginT.o和crtend.o來(lái)實(shí)現(xiàn)。我們?cè)诤竺娴恼鹿?jié)還會(huì)詳細(xì)分析它們的實(shí)現(xiàn)機(jī)制。
由于GCC支持諸多平臺(tái)，能夠正確處理不同平臺(tái)之間的差異性也是GCC的任務(wù)之一。比如有些32位平臺(tái)不支持64位的 longlong類型的運(yùn)算，編譯器不能夠直接產(chǎn)生相應(yīng)的CPU指令，而是需要一些輔助的例程來(lái)幫助實(shí)現(xiàn)計(jì)算。libgcc.a里面包含的就是這種類似的函數(shù)，這些函數(shù)主要包括整數(shù)運(yùn)算、浮點(diǎn)數(shù)運(yùn)算（不同的CPU對(duì)浮點(diǎn)數(shù)的運(yùn)算方法很不相同）等，而libgcc_eh.a則包含了支持C++的異常處理（ExceptionHandling）的平臺(tái)相關(guān)函數(shù)。另外GCC的安裝目錄下往往還有一個(gè)動(dòng)態(tài)鏈接版本的libgcc.a，為libgcc_s.so。
MSVC CRT
相比于相對(duì)自由分散的glibc，一直伴隨著不同版本的Visual C++發(fā)布的MSVCCRT（Microsoft Visual C++ C Runtime）倒看過(guò)去更加有序一些。從1992年最初的Visual C++1.0版開(kāi)始，一直到現(xiàn)在的Visual C++ 9.0（又叫做Visual C++ 2008），MSVCCRT也從1.0版發(fā)展到了9.0版。
同一個(gè)版本的MSVCCRT根據(jù)不同的屬性提供了多種子版本，以供不同需求的開(kāi)發(fā)者使用。按照靜態(tài)/動(dòng)態(tài)鏈接，可以分為靜態(tài)版和動(dòng)態(tài)版；按照單線程/多線程，可以分為單線程版和多線程版；按照調(diào)試/發(fā)布，可分為調(diào)試版和發(fā)布版；按照是否支持C++分為純C運(yùn)行庫(kù)版和支持C++版；按照是否支持托管代碼分為支持本地代碼/托管代碼和純托管代碼版。這些屬性很多時(shí)候是相互正交的，也就是說(shuō)它們之間可以相互組合。比如可以有靜態(tài)單線程純C純本地代碼調(diào)試版；也可以有動(dòng)態(tài)的多線程純C純本地代碼發(fā)布版等。但有些組合是沒(méi)有的，比如動(dòng)態(tài)鏈接版本的CRT是沒(méi)有單線程的，所有的動(dòng)態(tài)鏈接CRT都是多線程安全的。
這樣的不同組合將會(huì)出現(xiàn)非常多的子版本，于是微軟提供了一套運(yùn)行庫(kù)的命名方法。這個(gè)命名方法是這樣的，靜態(tài)版和動(dòng)態(tài)版完全不同。靜態(tài)版的CRT位于MSVC安裝目錄下的lib/，比如Visual C++ 2008的靜態(tài)庫(kù)路徑為“ProgramFiles/Microsoft Visual Studio 9.0/VC/lib”，它們的命名規(guī)則為：
libc [p] [mt] [d] .lib
l??????????p 表示 C Plusplus，即C++標(biāo)準(zhǔn)庫(kù)。
l??????????mt表示 Multi-Thread，即表示支持多線程。
l??????????d 表示 Debug，即表示調(diào)試版本。
比如靜態(tài)的非C++的多線程版CRT的文件名為libcmtd.lib。動(dòng)態(tài)版的CRT的每個(gè)版本一般有兩個(gè)相對(duì)應(yīng)的文件，一個(gè)用于鏈接的.lib文件，一個(gè)用于運(yùn)行時(shí)用的.dll動(dòng)態(tài)鏈接庫(kù)。它們的命名方式與靜態(tài)版的CRT非常類似，稍微有所不同的是，CRT的動(dòng)態(tài)鏈接庫(kù)DLL文件名中會(huì)包含版本號(hào)。比如Visual C++2005的多線程、動(dòng)態(tài)鏈接版的DLL文件名為msvcr90.dll（Visual C++2005的內(nèi)部版本號(hào)為8.0）。表11-1列舉了一些最常見(jiàn)的MSVC CRT版本（以Visual C++ 2005為例）。
表11-1
| 文件名 | 相關(guān)的DLL | 屬性 | 編譯器選項(xiàng) | 預(yù)編譯宏 |
| libcmt.lib | 無(wú) | 多線程，靜態(tài)鏈接 | /MT | _MT |
| msvcrt.lib | msvcr80.dll | 多線程，動(dòng)態(tài)鏈接 | /MD | _MT, _DLL |
| libcmtd.lib | 無(wú) | 多線程，靜態(tài)鏈接，調(diào)試 | /MTd | _DEBUG, _MT |
| msvcrtd.lib | msvcr90d.dll | 多線程，動(dòng)態(tài)鏈接，調(diào)試 | /MDd | _DEBUG, _MT, _DLL |
| msvcmrt.lib | msvcm90.dll | 托管/本地混合代碼 | /clr | ? |
| msvcurt.lib | msvcm90.dll | 純托管代碼 | /clr:pure | ? |
自從Visual C++ 2005（MSVC8.0）以后，MSVC不再提供靜態(tài)鏈接單線程版的運(yùn)行庫(kù)（LIBC.lib、LIBCD.lib），因?yàn)閾?jù)微軟聲稱，經(jīng)過(guò)改進(jìn)后的新的多線程版的C運(yùn)行庫(kù)在單線程的模式下運(yùn)行速度已經(jīng)接近單線程版的運(yùn)行庫(kù)，于是沒(méi)有必要再額外提供一個(gè)只支持單線程的CRT版本。
默認(rèn)情況下，如果在編譯鏈接時(shí)不指定鏈接哪個(gè)CRT，編譯器會(huì)默認(rèn)選擇LIBCMT.LIB，即靜態(tài)多線程CRT，Visual C++2005之前的版本會(huì)選擇LIBC.LIB，即靜態(tài)單線程版本。關(guān)于CRT的多線程和單線程的問(wèn)題，我們?cè)诤竺娴恼鹿?jié)還會(huì)再深入分析。
除了使用編譯命令行的選項(xiàng)之外，在VisualC++工程屬性中也可以設(shè)置相關(guān)選項(xiàng)。如圖11-9所示。
?
?
圖11-9?Visual C++ 2003 .NET工程屬性的截圖
我們可以從圖11-9中看到，除了多線程庫(kù)以外，還有單線程靜態(tài)/ML、單線程靜態(tài)調(diào)試/MLd的選項(xiàng)。
C++ CRT
表11-1中的所有CRT都是指C語(yǔ)言的標(biāo)準(zhǔn)庫(kù)，MSVC還提供了相應(yīng)的C++標(biāo)準(zhǔn)庫(kù)。如果你的程序是使用C++編寫的，那么就需要額外鏈接相應(yīng)的C++標(biāo)準(zhǔn)庫(kù)。這里“額外”的意思是，如表11-2所列的C++標(biāo)準(zhǔn)庫(kù)里面包含的僅僅是C++的內(nèi)容，比如iostream、string、map等，不包含C的標(biāo)準(zhǔn)庫(kù)。
表11-2
| 文件名 | 相應(yīng)DLL | 屬性 | 編譯選項(xiàng) | 宏定義 |
| LIBCPMT.LIB | 無(wú) | 多線程，靜態(tài)鏈接 | /MT | _MT |
| MSVCPRT.LIB | MSVCP90.dll | 多線程，動(dòng)態(tài)鏈接 | /MD | _MT, _DLL |
| LIBCPMTD.LIB | 無(wú) | 多線程，靜態(tài)鏈接，調(diào)試 | /MTd | _DEBUG, _MT |
| MSVCPRTD.LIB | MSVCP90D.dll | 多線程，動(dòng)態(tài)鏈接，調(diào)試 | /MDd | _DEBUG, _MT, _DLL |
當(dāng)你在程序里包含了某個(gè)C++標(biāo)準(zhǔn)庫(kù)的頭文件時(shí)，MSVC編譯器就認(rèn)為該源代碼文件是一個(gè)C++源代碼程序，它會(huì)在編譯時(shí)根據(jù)編譯選項(xiàng)，在目標(biāo)文件的“.drectve”段（還記得第2章中的DIRECTIVE吧？）相應(yīng)的C++標(biāo)準(zhǔn)庫(kù)鏈接信息。比如我們用C++寫一個(gè)“Hello World”程序：
// hello.cpp
#include<iostream>
int main()
{
??? std::cout<< "Hello world"<< std::endl;
??? return0;
}
然后將它編譯成目標(biāo)文件，并查看它的“.drectve”段的信息：
cl /c hello.cpp
dumpbin /DIRECTIVEShello.obj
Microsoft (R) COFF/PE Dumper Version9.00.21022.08
Copyright (C) MicrosoftCorporation.? All rights reserved.
Dump of file msvcprt.obj
File Type: COFF OBJECT
?? LinkerDirectives
??-----------------
??/DEFAULTLIB:"libcpmt"
??/DEFAULTLIB:"LIBCMT"
??/DEFAULTLIB:"OLDNAMES"
cl /c /MDdhello.cpp
dumpbin /DIRECTIVEShello.obj
Microsoft (R) COFF/PE Dumper Version9.00.21022.08
Copyright (C) MicrosoftCorporation.? All rights reserved.
Dump of file msvcprt.obj
File Type: COFF OBJECT
?? LinkerDirectives
??-----------------
??/manifestdependency:"type='win32'
??name='Microsoft.VC90.DebugCRT'
??version='9.0.21022.8'
??processorArchitecture='x86'
??publicKeyToken='1fc8b3b9a1e18e3b'"
??/DEFAULTLIB:"msvcprtd"
??/manifestdependency:"type='win32'
??name='Microsoft.VC90.DebugCRT'
??version='9.0.21022.8'
??processorArchitecture='x86'
??publicKeyToken='1fc8b3b9a1e18e3b'"
??/DEFAULTLIB:"MSVCRTD"
??/DEFAULTLIB:"OLDNAMES"
可以看到，hello.obj須要鏈接libcpmt.lib、LIBCMT.lib和OLDNAMES.lib。當(dāng)我們使用“/MDd”參數(shù)編譯時(shí)，hello.obj就需要msvcprtd.lib、MSVCRTD.lib和OLDNAMES.lib，除此之外，編譯器還給鏈接器傳遞了“/manifestdependency”參數(shù)，即manifest信息。
Q&A
Q：如果一個(gè)程序里面的不同obj文件或DLL文件使用了不同的CRT，會(huì)不會(huì)有問(wèn)題？
A：這個(gè)問(wèn)題實(shí)際上分很多種情況。如果程序沒(méi)有用到DLL，完全靜態(tài)鏈接，不同的obj在編譯時(shí)用到了不同版本的靜態(tài)CRT。由于目前靜態(tài)鏈接CRT只有多線程版，并且如果所有的目標(biāo)文件都統(tǒng)一使用調(diào)試版或發(fā)布版，那么這種情況下一般是不會(huì)有問(wèn)題的。因?yàn)槲覀冎?#xff0c;目標(biāo)文件對(duì)靜態(tài)庫(kù)引用只是在目標(biāo)文件的符號(hào)表中保留一個(gè)記號(hào)，并不進(jìn)行實(shí)際的鏈接，也沒(méi)有靜態(tài)庫(kù)的版本信息。
??????但是，如果程序涉及動(dòng)態(tài)鏈接CRT，這就比較復(fù)雜了。因?yàn)椴煌哪繕?biāo)文件如果依賴于不同版本的msvcrt.lib和msvcrt.dll，甚至有些目標(biāo)文件是依賴于靜態(tài)CRT，而有些目標(biāo)文件依賴于動(dòng)態(tài)CRT，那么很有可能出現(xiàn)的問(wèn)題就是無(wú)法通過(guò)鏈接。鏈接器對(duì)這種情況的具體反應(yīng)依賴于輸入目標(biāo)文件的順序，有些情況下它會(huì)報(bào)符號(hào)重復(fù)定義錯(cuò)誤：
??????MSVCRTD.lib(MSVCR80D.dll) : error LNK2005: _printf already definedin LIBCMTD.lib (printf.obj)
??????但是有些情況下，它會(huì)使鏈接順利通過(guò)，只是給出一個(gè)警告：
??????LINK : warning LNK4098: defaultlib 'LIBCMTD' conflicts with use ofother libs; use /NODEFAULTLIB:library
??????如果碰到上面這種靜態(tài)/動(dòng)態(tài)CRT混合的情況，我們可以使用鏈接器的/NODEFAULTLIB來(lái)禁止某個(gè)或某些版本的CRT，這樣一般就能使鏈接順利進(jìn)行。
??????最麻煩的情況應(yīng)該屬于一個(gè)程序所依賴的DLL分別使用不同的CRT，這會(huì)導(dǎo)致程序在運(yùn)行時(shí)同時(shí)有多份CRT的副本。在一般情況下，這個(gè)程序應(yīng)該能正常運(yùn)行，但是值得注意的是，你不能夠在這些DLL之間相互傳遞使用一些資源。比如兩個(gè)DLLA和B分別使用不同的CRT，那么應(yīng)該注意以下問(wèn)題：
????l????不能在A中申請(qǐng)內(nèi)存然后在B中釋放，因?yàn)樗鼈兎謱儆诓煌腃RT，即擁有不同的堆，這包括C++里面所有對(duì)象的申請(qǐng)和釋放；
????l????在A中打開(kāi)的文件不能在B中使用，比如FILE*之類的，因?yàn)樗鼈円蕾囉贑RT的文件操作部分。
??????還有類似的問(wèn)題，比如不能相互共享locale等。如果不違反上述規(guī)則，可能會(huì)使程序發(fā)生莫名其妙的錯(cuò)誤并且很難發(fā)現(xiàn)。
??????防止出現(xiàn)上述問(wèn)題的最好方法就是保證一個(gè)工程里面所有的目標(biāo)文件和DLL都使用同一個(gè)版本的CRT。當(dāng)然有時(shí)候事實(shí)并不能盡如人意，比如很多時(shí)候當(dāng)我們要用到第三方提供的.lib或DLL文件而對(duì)方又不提供源代碼時(shí)，就會(huì)比較難辦。
??????Windows系統(tǒng)的system32目錄下有個(gè)叫msvcrt.dll的文件，它跟msvcr90.dll這樣的DLL有什么區(qū)別？
Q：為什么我用Visual C++2005/2008編譯的程序無(wú)法在別人的機(jī)器上運(yùn)行？
A：因?yàn)閂isual C++2005/2008編譯的程序使用了manifest機(jī)制，這些程序必須依賴于相對(duì)應(yīng)版本的運(yùn)行庫(kù)。一個(gè)解決的方法就是使用靜態(tài)鏈接，這樣就不需要依賴于CRT的DLL。另外一個(gè)解決的方法就是將相應(yīng)版本的運(yùn)行庫(kù)與程序一起發(fā)布給最終用戶。
創(chuàng)作挑戰(zhàn)賽新人創(chuàng)作獎(jiǎng)勵(lì)來(lái)咯，堅(jiān)持創(chuàng)作打卡瓜分現(xiàn)金大獎(jiǎng)總結(jié)
- 上一篇： linux 中 timeval结构体
- 下一篇： 31省份新增本土20+54：上海新增本土