http://www.360doc.com/content/13/0502/17/9192936_282472350.shtml

在編譯一個ffmepg AAC解碼測試程式時，遇到了如下錯誤輸出：

1. 1>main.obj : error LNK2001: 無法解析的外部符號 "int __cdecl avcodec_open(struct AVCodecContext *,struct AVCodec *)" ([email protected]@[email protected]@[email protected]@@Z)  
2. 1>main.obj : error LNK2001: 無法解析的外部符號 "struct AVCodec * __cdecl avcodec_find_decoder(enum CodecID)" (
   [email protected]@[email protected]@[email protected]@@Z)  
3. 1>main.obj : error LNK2001: 無法解析的外部符號 "void __cdecl dump_format(struct AVFormatContext *,int,char const *,int)" ([email protected]@[email protected]@[email protected])  
4. 1>main.obj : error LNK2001: 無法解析的外部符號 "int __cdecl av_find_stream_info(struct AVFormatContext *)" (
   [email protected]@[email protected]@@Z)  
5. 1>main.obj : error LNK2001: 無法解析的外部符號 "int __cdecl av_open_input_file(struct AVFormatContext * *,char const *,struct AVInputFormat *,int,struct AVFormatParameters *)" ([email protected]@[email protected]@[email protected]@[email protected]
   @@Z)  
6. 1>main.obj : error LNK2001: 無法解析的外部符號 "struct AVFormatContext * __cdecl av_alloc_format_context(void)" ([email protected]@[email protected]@XZ)  
7. 1>main.obj : error LNK2001: 無法解析的外部符號 "void __cdecl av_register_all(void)" ([email protected]@YAXXZ)  
8. 1>main.obj : error LNK2001: 無法解析的外部符號 "void __cdecl av_free(void *)" ([email protected]@[email protected])  
9. 1>main.obj : error LNK2001: 無法解析的外部符號 "int __cdecl avcodec_close(struct AVCodecContext *)" ([email protected]@[email protected]@@Z)  
10. 1>main.obj : error LNK2001: 無法解析的外部符號 "int __cdecl avcodec_decode_audio3(struct AVCodecContext *,short *,int *,struct AVPacket *)" ([email protected]@[email protected]@[email protected]@@Z)  
11. 1>main.obj : error LNK2001: 無法解析的外部符號 "int __cdecl av_read_frame(struct AVFormatContext *,struct AVPacket *)" ([email protected]@[email protected]@[email protected]@@Z)  
12. 1>main.obj : error LNK2001: 無法解析的外部符號 "void __cdecl av_init_packet(struct AVPacket *)" ([email protected]@[email protected]@@Z)  
13. 1>main.obj : error LNK2001: 無法解析的外部符號 "void * __cdecl av_malloc(unsigned int)" ([email protected]@[email protected])  

可以確定自己正確連結了lib檔案，為何還會出現連結錯誤呢？更奇怪的是，將呼叫這些外部函式的檔案（test.cpp）改成test.c後，編譯又成功了？哪裡出了問題呢？

問題出在使用在C++中呼叫C語言編寫的動態連結庫時，要在與DLL相應的標頭檔案中新增extern “C”。

那為什麼要extern “C”呢？這要從C++與C不同的編譯和連線方式說起：

        C++語言的建立初衷是“a better C”，但是這並不意味著C++中類似C語言的全域性變數和函式所採用的編譯和連線方式與C語言完全相同。作為一種欲與C相容的語言，C++保留了一部分過程式語言的特點（被世人稱為“不徹底地面向物件”），因而它可以定義不屬於任何類的全域性變數和函式。但是，C++畢竟是一種面向物件的程式設計語言，為了支援函式的過載，C++對全域性函式的處理方式與C有明顯的不同。

作為一種面向物件的語言，C++支援函式過載，而過程式語言C則不支援。函式被C++編譯後在符號庫中的名字與C語言的不同。例如，假設某個函式的原型為：

void foo( int x, int y );
　　該函式被C編譯器編譯後在符號庫中的名字為_foo，而C++編譯器則會產生像_foo_int_int之類的名字（不同的編譯器可能生成的名字不同，但是都採用了相同的機制，生成的新名字稱為“mangled name”）。

　　_foo_int_int這樣的名字包含了函式名、函式引數數量及型別資訊，C++就是靠這種機制來實現函式過載的。例如，在C++中，函式void foo( int x, int y )與void foo( int x, float y )編譯生成的符號是不相同的，後者為_foo_int_float。
　　同樣地，C++中的變數除支援區域性變數外，還支援類成員變數和全域性變數。使用者所編寫程式的類成員變數可能與全域性變數同名，我們以"."來區分。而本質上，編譯器在進行編譯時，與函式的處理相似，也為類中的變數取了一個獨一無二的名字，這個名字與使用者程式中同名的全域性變數名字不同。

時常在cpp的程式碼之中看到這樣的程式碼: 

1. #ifdef __cplusplus  
2. extern "C" {  
3. #endif  
4. //一段程式碼  
5. #ifdef __cplusplus  
6. }  
7. #endif  

1. int f(void)  
2. {  
3. return 1;  
4. }  

1. .file "test.cxx"  
2. .text  
3. .align 2  
4. .globl _f  
5. .def _f; .scl 2; .type 32; .endef  
6. _f:  
7. pushl %ebp  
8. movl %esp， %ebp  
9. movl $1， %eax  
10. popl %ebp  
11. ret  

1. .file "test.cxx"  
2. .text  
3. .align 2  
4. .globl __Z1fv  
5. .def __Z1fv; .scl 2; .type 32; .endef  
6. __Z1fv:  
7. pushl %ebp  
8. movl %esp， %ebp  
9. movl $1， %eax  
10. popl %ebp  
11. ret  

1. //f1.c  
2. extern "C"  
3. {  
4. void f1()  
5. {  
6. return;  
7. }  
8. }  

1. // test.cxx  
2. //這個extern表示f1函式在別的地方定義，這樣可以通過  
3. //編譯，但是連結的時候還是需要  
4. //連結上原來的庫檔案.  
5. extern void f1();  
6. int main()  
7. {  
8. f1();  
9. return 0;  
10. }  

1. test.o(.text + 0x1f):test.cxx: undefine reference to 'f1()'  

1. extern "C"  
2. {  
3. #include "f.h"  
4. }  

1. extern "C"  
2. {  
3. extern void f1();  
4. }  
5. int main()  
6. {  
7. f1();  
8. return 0;  
9. }