在編譯一個(gè)ffmepg AAC解碼測試程序時(shí)，遇到了如下錯(cuò)誤輸出：
- 1>main.obj : error LNK2001: 無法解析的外部符號(hào) "int __cdecl avcodec_open(struct AVCodecContext *,struct AVCodec *)" (?avcodec_open@@YAHPAUAVCodecContext@@PAUAVCodec@@@Z)
- 1>main.obj : error LNK2001: 無法解析的外部符號(hào) "struct AVCodec * __cdecl avcodec_find_decoder(enum CodecID)" (?avcodec_find_decoder@@YAPAUAVCodec@@W4CodecID@@@Z)
- 1>main.obj : error LNK2001: 無法解析的外部符號(hào) "void __cdecl dump_format(struct AVFormatContext *,int,char const *,int)" (?dump_format@@YAXPAUAVFormatContext@@HPBDH@Z)
- 1>main.obj : error LNK2001: 無法解析的外部符號(hào) "int __cdecl av_find_stream_info(struct AVFormatContext *)" (?av_find_stream_info@@YAHPAUAVFormatContext@@@Z)
- 1>main.obj : error LNK2001: 無法解析的外部符號(hào) "int __cdecl av_open_input_file(struct AVFormatContext * *,char const *,struct AVInputFormat *,int,struct AVFormatParameters *)" (?av_open_input_file@@YAHPAPAUAVFormatContext@@PBDPAUAVInputFormat@@HPAUAVFormatParameters@@@Z)
- 1>main.obj : error LNK2001: 無法解析的外部符號(hào) "struct AVFormatContext * __cdecl av_alloc_format_context(void)" (?av_alloc_format_context@@YAPAUAVFormatContext@@XZ)
- 1>main.obj : error LNK2001: 無法解析的外部符號(hào) "void __cdecl av_register_all(void)" (?av_register_all@@YAXXZ)
- 1>main.obj : error LNK2001: 無法解析的外部符號(hào) "void __cdecl av_free(void *)" (?av_free@@YAXPAX@Z)
- 1>main.obj : error LNK2001: 無法解析的外部符號(hào) "int __cdecl avcodec_close(struct AVCodecContext *)" (?avcodec_close@@YAHPAUAVCodecContext@@@Z)
- 1>main.obj : error LNK2001: 無法解析的外部符號(hào) "int __cdecl avcodec_decode_audio3(struct AVCodecContext *,short *,int *,struct AVPacket *)" (?avcodec_decode_audio3@@YAHPAUAVCodecContext@@PAFPAHPAUAVPacket@@@Z)
- 1>main.obj : error LNK2001: 無法解析的外部符號(hào) "int __cdecl av_read_frame(struct AVFormatContext *,struct AVPacket *)" (?av_read_frame@@YAHPAUAVFormatContext@@PAUAVPacket@@@Z)
- 1>main.obj : error LNK2001: 無法解析的外部符號(hào) "void __cdecl av_init_packet(struct AVPacket *)" (?av_init_packet@@YAXPAUAVPacket@@@Z)
- 1>main.obj : error LNK2001: 無法解析的外部符號(hào) "void * __cdecl av_malloc(unsigned int)" (?av_malloc@@YAPAXI@Z)
可以確定自己正確鏈接了lib文件，為何還會(huì)出現(xiàn)鏈接錯(cuò)誤呢？更奇怪的是，將調(diào)用這些外部函數(shù)的文件（test.cpp）改成test.c后，編譯又成功了？哪里出了問題呢？
問題出在使用在C++中調(diào)用C語言編寫的動(dòng)態(tài)鏈接庫時(shí)，要在與DLL相應(yīng)的頭文件中添加extern “C”。
那為什么要extern “C”呢？這要從C++與C不同的編譯和連接方式說起：
以下文字轉(zhuǎn)載于：http://www.cppblog.com/Macaulish/archive/2008/06/17/53689.html
C++語言的創(chuàng)建初衷是“a better C”，但是這并不意味著C++中類似C語言的全局變量和函數(shù)所采用的編譯和連接方式與C語言完全相同。作為一種欲與C兼容的語言，C++保留了一部分過程式語言的特點(diǎn)（被世人稱為“不徹底地面向?qū)ο蟆保?，因而它可以定義不屬于任何類的全局變量和函數(shù)。但是，C++畢竟是一種面向?qū)ο蟮某绦蛟O(shè)計(jì)語言，為了支持函數(shù)的重載，C++對(duì)全局函數(shù)的處理方式與C有明顯的不同。
作為一種面向?qū)ο蟮恼Z言，C++支持函數(shù)重載，而過程式語言C則不支持。函數(shù)被C++編譯后在符號(hào)庫中的名字與C語言的不同。例如，假設(shè)某個(gè)函數(shù)的原型為：
void foo( int x, int y );
該函數(shù)被C編譯器編譯后在符號(hào)庫中的名字為_foo，而C++編譯器則會(huì)產(chǎn)生像_foo_int_int之類的名字（不同的編譯器可能生成的名字不同，但是都采用了相同的機(jī)制，生成的新名字稱為“mangled name”）。
_foo_int_int這樣的名字包含了函數(shù)名、函數(shù)參數(shù)數(shù)量及類型信息，C++就是靠這種機(jī)制來實(shí)現(xiàn)函數(shù)重載的。例如，在C++中，函數(shù)void foo( int x, int y )與void foo( int x, float y )編譯生成的符號(hào)是不相同的，后者為_foo_int_float。
同樣地，C++中的變量除支持局部變量外，還支持類成員變量和全局變量。用戶所編寫程序的類成員變量可能與全局變量同名，我們以"."來區(qū)分。而本質(zhì)上，編譯器在進(jìn)行編譯時(shí)，與函數(shù)的處理相似，也為類中的變量取了一個(gè)獨(dú)一無二的名字，這個(gè)名字與用戶程序中同名的全局變量名字不同。
以下文字轉(zhuǎn)載于：http://tech.163.com/06/0118/09/27O66HCC0009159Q.html
時(shí)常在cpp的代碼之中看到這樣的代碼:
- #ifdef __cplusplus
- extern "C" {
- #endif
-
-
-
- #ifdef __cplusplus
- }
- #endif
這樣的代碼到底是什么意思呢？首先，__cplusplus是cpp中的自定義宏，那么定義了這個(gè)宏的話表示這是一段cpp的代碼，也就是說，上面的代碼的含義是:如果這是一段cpp的代碼，那么加入extern "C"{和}處理其中的代碼。
要明白為何使用extern "C"，還得從cpp中對(duì)函數(shù)的重載處理開始說起。在c++中，為了支持重載機(jī)制，在編譯生成的匯編碼中，要對(duì)函數(shù)的名字進(jìn)行一些處理，加入比如函數(shù)的返回類型等等.而在C中，只是簡單的函數(shù)名字而已，不會(huì)加入其他的信息.也就是說:C++和C對(duì)產(chǎn)生的函數(shù)名字的處理是不一樣的.
比如下面的一段簡單的函數(shù)，我們看看加入和不加入extern "C"產(chǎn)生的匯編代碼都有哪些變化:
- int f(void)
- {
- return 1;
- }
在加入extern "C"的時(shí)候產(chǎn)生的匯編代碼是:
- .file "test.cxx"
- .text
- .align 2
- .globl _f
- .def _f; .scl 2; .type 32; .endef
- _f:
- pushl %ebp
- movl %esp， %ebp
- movl $1， %eax
- popl %ebp
- ret
但是不加入了extern "C"之后
- .file "test.cxx"
- .text
- .align 2
- .globl __Z1fv
- .def __Z1fv; .scl 2; .type 32; .endef
- __Z1fv:
- pushl %ebp
- movl %esp， %ebp
- movl $1， %eax
- popl %ebp
- ret
兩段匯編代碼同樣都是使用gcc -S命令產(chǎn)生的，所有的地方都是一樣的，唯獨(dú)是產(chǎn)生的函數(shù)名，一個(gè)是_f，一個(gè)是__Z1fv。
明白了加入與不加入extern "C"之后對(duì)函數(shù)名稱產(chǎn)生的影響，我們繼續(xù)我們的討論:為什么需要使用extern "C"呢？C++之父在設(shè)計(jì)C++之時(shí)，考慮到當(dāng)時(shí)已經(jīng)存在了大量的C代碼，為了支持原來的C代碼和已經(jīng)寫好C庫，需要在C++中盡可能的支持C，而extern "C"就是其中的一個(gè)策略。
試想這樣的情況:一個(gè)庫文件已經(jīng)用C寫好了而且運(yùn)行得很良好，這個(gè)時(shí)候我們需要使用這個(gè)庫文件，但是我們需要使用C++來寫這個(gè)新的代碼。如果這個(gè)代碼使用的是C++的方式鏈接這個(gè)C庫文件的話，那么就會(huì)出現(xiàn)鏈接錯(cuò)誤.我們來看一段代碼:首先，我們使用C的處理方式來寫一個(gè)函數(shù)，也就是說假設(shè)這個(gè)函數(shù)當(dāng)時(shí)是用C寫成的:
- //f1.c
- extern "C"
- {
- void f1()
- {
- return;
- }
- }
編譯命令是:gcc -c f1.c -o f1.o 產(chǎn)生了一個(gè)叫f1.o的庫文件。再寫一段代碼調(diào)用這個(gè)f1函數(shù):
- // test.cxx
- //這個(gè)extern表示f1函數(shù)在別的地方定義，這樣可以通過
- //編譯，但是鏈接的時(shí)候還是需要
- //鏈接上原來的庫文件.
- extern void f1();
-
- int main()
- {
- f1();
-
- return 0;
- }
通過gcc -c test.cxx -o test.o 產(chǎn)生一個(gè)叫test.o的文件。然后，我們使用gcc test.o f1.o來鏈接兩個(gè)文件，可是出錯(cuò)了，錯(cuò)誤的提示是:
- test.o(.text + 0x1f):test.cxx: undefine reference to 'f1()'
也就是說，在編譯test.cxx的時(shí)候編譯器是使用C++的方式來處理f1()函數(shù)的，但是實(shí)際上鏈接的庫文件卻是用C的方式來處理函數(shù)的，所以就會(huì)出現(xiàn)鏈接過不去的錯(cuò)誤:因?yàn)殒溄悠髡也坏胶瘮?shù)。
因此，為了在C++代碼中調(diào)用用C寫成的庫文件，就需要用extern "C"來告訴編譯器:這是一個(gè)用C寫成的庫文件，請(qǐng)用C的方式來鏈接它們。
比如，現(xiàn)在我們有了一個(gè)C庫文件，它的頭文件是f.h，產(chǎn)生的lib文件是f.lib，那么我們?nèi)绻贑++中使用這個(gè)庫文件，我們需要這樣寫:
- extern "C"
- {
- #include "f.h"
- }
回到上面的問題，如果要改正鏈接錯(cuò)誤，我們需要這樣子改寫test.cxx:
- extern "C"
- {
- extern void f1();
- }
-
- int main()
- {
- f1();
-
- return 0;
- }
重新編譯并且鏈接就可以過去了.
總結(jié) C和C++對(duì)函數(shù)的處理方式是不同的.extern "C"是使C++能夠調(diào)用C寫作的庫文件的一個(gè)手段，如果要對(duì)編譯器提示使用C的方式來處理函數(shù)的話，那么就要使用extern "C"來說明。
