ffmpeg链接错误:关于C++ extern C

2024-06-01 07:38
文章标签 c++ ffmpeg 错误 链接 extern

本文主要是介绍ffmpeg链接错误:关于C++ extern C,希望对大家解决编程问题提供一定的参考价值,需要的开发者们随着小编来一起学习吧!

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


在编译一个ffmepg AAC解码测试程序时,遇到了如下错误输出:

[html]  view plain copy ?
  1. 1>main.obj : error LNK2001: 无法解析的外部符号 "int __cdecl avcodec_open(struct AVCodecContext *,struct AVCodec *)" (?avcodec_open@@YAHPAUAVCodecContext@@PAUAVCodec@@@Z)  
  2. 1>main.obj : error LNK2001: 无法解析的外部符号 "struct AVCodec * __cdecl avcodec_find_decoder(enum CodecID)" (?avcodec_find_decoder@@YAPAUAVCodec@@W4CodecID@@@Z)  
  3. 1>main.obj : error LNK2001: 无法解析的外部符号 "void __cdecl dump_format(struct AVFormatContext *,int,char const *,int)" (?dump_format@@YAXPAUAVFormatContext@@HPBDH@Z)  
  4. 1>main.obj : error LNK2001: 无法解析的外部符号 "int __cdecl av_find_stream_info(struct AVFormatContext *)" (?av_find_stream_info@@YAHPAUAVFormatContext@@@Z)  
  5. 1>main.obj : error LNK2001: 无法解析的外部符号 "int __cdecl av_open_input_file(struct AVFormatContext * *,char const *,struct AVInputFormat *,int,struct AVFormatParameters *)" (?av_open_input_file@@YAHPAPAUAVFormatContext@@PBDPAUAVInputFormat@@HPAUAVFormatParameters@@@Z)  
  6. 1>main.obj : error LNK2001: 无法解析的外部符号 "struct AVFormatContext * __cdecl av_alloc_format_context(void)" (?av_alloc_format_context@@YAPAUAVFormatContext@@XZ)  
  7. 1>main.obj : error LNK2001: 无法解析的外部符号 "void __cdecl av_register_all(void)" (?av_register_all@@YAXXZ)  
  8. 1>main.obj : error LNK2001: 无法解析的外部符号 "void __cdecl av_free(void *)" (?av_free@@YAXPAX@Z)  
  9. 1>main.obj : error LNK2001: 无法解析的外部符号 "int __cdecl avcodec_close(struct AVCodecContext *)" (?avcodec_close@@YAHPAUAVCodecContext@@@Z)  
  10. 1>main.obj : error LNK2001: 无法解析的外部符号 "int __cdecl avcodec_decode_audio3(struct AVCodecContext *,short *,int *,struct AVPacket *)" (?avcodec_decode_audio3@@YAHPAUAVCodecContext@@PAFPAHPAUAVPacket@@@Z)  
  11. 1>main.obj : error LNK2001: 无法解析的外部符号 "int __cdecl av_read_frame(struct AVFormatContext *,struct AVPacket *)" (?av_read_frame@@YAHPAUAVFormatContext@@PAUAVPacket@@@Z)  
  12. 1>main.obj : error LNK2001: 无法解析的外部符号 "void __cdecl av_init_packet(struct AVPacket *)" (?av_init_packet@@YAXPAUAVPacket@@@Z)  
  13. 1>main.obj : error LNK2001: 无法解析的外部符号 "void * __cdecl av_malloc(unsigned int)" (?av_malloc@@YAPAXI@Z)  

可以确定自己正确链接了lib文件,为何还会出现链接错误呢?更奇怪的是,将调用这些外部函数的文件(test.cpp)改成test.c后,编译又成功了?哪里出了问题呢?

问题出在使用在C++中调用C语言编写的动态链接库时,要在与DLL相应的头文件中添加extern “C”

那为什么要extern “C”呢?这要从C++与C不同的编译和连接方式说起:


以下文字转载于:http://www.cppblog.com/Macaulish/archive/2008/06/17/53689.html

        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++中的变量除支持局部变量外,还支持类成员变量和全局变量。用户所编写程序的类成员变量可能与全局变量同名,我们以"."来区分。而本质上,编译器在进行编译时,与函数的处理相似,也为类中的变量取了一个独一无二的名字,这个名字与用户程序中同名的全局变量名字不同。


以下文字转载于:http://tech.163.com/06/0118/09/27O66HCC0009159Q.html

时常在cpp的代码之中看到这样的代码: 

[cpp]  view plain copy ?
  1. #ifdef __cplusplus  
  2. extern "C" {  
  3. #endif  
  4.   
  5. //一段代码  
  6.   
  7. #ifdef __cplusplus  
  8. }  
  9. #endif  

  这样的代码到底是什么意思呢?首先,__cplusplus是cpp中的自定义宏,那么定义了这个宏的话表示这是一段cpp的代码,也就是说,上面的代码的含义是:如果这是一段cpp的代码,那么加入extern "C"{和}处理其中的代码。

  要明白为何使用extern "C",还得从cpp中对函数的重载处理开始说起。在c++中,为了支持重载机制,在编译生成的汇编码中,要对函数的名字进行一些处理,加入比如函数的返回类型等等.而在C中,只是简单的函数名字而已,不会加入其他的信息.也就是说:C++和C对产生的函数名字的处理是不一样的.

  比如下面的一段简单的函数,我们看看加入和不加入extern "C"产生的汇编代码都有哪些变化:

[html]  view plain copy ?
  1. int f(void)  
  2. {  
  3. return 1;  
  4. }  
  在加入extern "C"的时候产生的汇编代码是:
[html]  view plain copy ?
  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  
  但是不加入了extern "C"之后
[html]  view plain copy ?
  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  
  两段汇编代码同样都是使用gcc -S命令产生的,所有的地方都是一样的,唯独是产生的函数名,一个是_f,一个是__Z1fv。

  明白了加入与不加入extern "C"之后对函数名称产生的影响,我们继续我们的讨论:为什么需要使用extern "C"呢?C++之父在设计C++之时,考虑到当时已经存在了大量的C代码,为了支持原来的C代码和已经写好C库,需要在C++中尽可能的支持C,而extern "C"就是其中的一个策略。

  试想这样的情况:一个库文件已经用C写好了而且运行得很良好,这个时候我们需要使用这个库文件,但是我们需要使用C++来写这个新的代码。如果这个代码使用的是C++的方式链接这个C库文件的话,那么就会出现链接错误.我们来看一段代码:首先,我们使用C的处理方式来写一个函数,也就是说假设这个函数当时是用C写成的:
[html]  view plain copy ?
  1. //f1.c  
  2. extern "C"  
  3. {  
  4. void f1()  
  5. {  
  6. return;  
  7. }  
  8. }  
  编译命令是:gcc -c f1.c -o f1.o 产生了一个叫f1.o的库文件。再写一段代码调用这个f1函数:
[html]  view plain copy ?
  1. // test.cxx  
  2. //这个extern表示f1函数在别的地方定义,这样可以通过  
  3. //编译,但是链接的时候还是需要  
  4. //链接上原来的库文件.  
  5. extern void f1();  
  6.   
  7. int main()  
  8. {  
  9. f1();  
  10.   
  11. return 0;  
  12. }  
  通过gcc -c test.cxx -o test.o 产生一个叫test.o的文件。然后,我们使用gcc test.o f1.o来链接两个文件,可是出错了,错误的提示是:
[html]  view plain copy ?
  1. test.o(.text + 0x1f):test.cxx: undefine reference to 'f1()'  
  也就是说,在编译test.cxx的时候编译器是使用C++的方式来处理f1()函数的,但是实际上链接的库文件却是用C的方式来处理函数的,所以就会出现链接过不去的错误:因为链接器找不到函数。

  因此,为了在C++代码中调用用C写成的库文件,就需要用extern "C"来告诉编译器:这是一个用C写成的库文件,请用C的方式来链接它们。

  比如,现在我们有了一个C库文件,它的头文件是f.h,产生的lib文件是f.lib,那么我们如果要在C++中使用这个库文件,我们需要这样写:
[html]  view plain copy ?
  1. extern "C"  
  2. {  
  3. #include "f.h"  
  4. }  
  回到上面的问题,如果要改正链接错误,我们需要这样子改写test.cxx:
[html]  view plain copy ?
  1. extern "C"  
  2. {  
  3. extern void f1();  
  4. }  
  5.   
  6. int main()  
  7. {  
  8. f1();  
  9.   
  10. return 0;  
  11. }  

  重新编译并且链接就可以过去了.

  总结


  C和C++对函数的处理方式是不同的.extern "C"是使C++能够调用C写作的库文件的一个手段,如果要对编译器提示使用C的方式来处理函数的话,那么就要使用extern "C"来说明。

这篇关于ffmpeg链接错误:关于C++ extern C的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!



http://www.chinasem.cn/article/1020385

相关文章

Ubuntu上手动安装Go环境并解决“可执行文件格式错误”问题

《Ubuntu上手动安装Go环境并解决“可执行文件格式错误”问题》:本文主要介绍Ubuntu上手动安装Go环境并解决“可执行文件格式错误”问题,具有很好的参考价值,希望对大家有所帮助,如有错误或未... 目录一、前言二、系统架构检测三、卸载旧版 Go四、下载并安装正确版本五、配置环境变量六、验证安装七、常见

正则表达式r前缀使用指南及如何避免常见错误

《正则表达式r前缀使用指南及如何避免常见错误》正则表达式是处理字符串的强大工具,但它常常伴随着转义字符的复杂性,本文将简洁地讲解r的作用、基本原理,以及如何在实际代码中避免常见错误,感兴趣的朋友一... 目录1. 字符串的双重翻译困境2. 为什么需要 r?3. 常见错误和正确用法4. Unicode 转换的

C++类和对象之初始化列表的使用方式

《C++类和对象之初始化列表的使用方式》:本文主要介绍C++类和对象之初始化列表的使用方式,具有很好的参考价值,希望对大家有所帮助,如有错误或未考虑完全的地方,望不吝赐教... 目录C++初始化列表详解:性能优化与正确实践什么是初始化列表?初始化列表的三大核心作用1. 性能优化:避免不必要的赋值操作2. 强

C++迭代器失效的避坑指南

《C++迭代器失效的避坑指南》在C++中,迭代器(iterator)是一种类似指针的对象,用于遍历STL容器(如vector、list、map等),迭代器失效是指在对容器进行某些操作后... 目录1. 什么是迭代器失效?2. 哪些操作会导致迭代器失效?2.1 vector 的插入操作(push_back,

Android NDK版本迭代与FFmpeg交叉编译完全指南

《AndroidNDK版本迭代与FFmpeg交叉编译完全指南》在Android开发中,使用NDK进行原生代码开发是一项常见需求,特别是当我们需要集成FFmpeg这样的多媒体处理库时,本文将深入分析A... 目录一、android NDK版本迭代分界线二、FFmpeg交叉编译关键注意事项三、完整编译脚本示例四

解决tomcat启动时报Junit相关错误java.lang.ClassNotFoundException: org.junit.Test问题

《解决tomcat启动时报Junit相关错误java.lang.ClassNotFoundException:org.junit.Test问题》:本文主要介绍解决tomcat启动时报Junit相... 目录tomcat启动时报Junit相关错误Java.lang.ClassNotFoundException

Java NoClassDefFoundError运行时错误分析解决

《JavaNoClassDefFoundError运行时错误分析解决》在Java开发中,NoClassDefFoundError是一种常见的运行时错误,它通常表明Java虚拟机在尝试加载一个类时未能... 目录前言一、问题分析二、报错原因三、解决思路检查类路径配置检查依赖库检查类文件调试类加载器问题四、常见

C#如何调用C++库

《C#如何调用C++库》:本文主要介绍C#如何调用C++库方式,具有很好的参考价值,希望对大家有所帮助,如有错误或未考虑完全的地方,望不吝赐教... 目录方法一:使用P/Invoke1. 导出C++函数2. 定义P/Invoke签名3. 调用C++函数方法二:使用C++/CLI作为桥接1. 创建C++/CL

C++如何通过Qt反射机制实现数据类序列化

《C++如何通过Qt反射机制实现数据类序列化》在C++工程中经常需要使用数据类,并对数据类进行存储、打印、调试等操作,所以本文就来聊聊C++如何通过Qt反射机制实现数据类序列化吧... 目录设计预期设计思路代码实现使用方法在 C++ 工程中经常需要使用数据类,并对数据类进行存储、打印、调试等操作。由于数据类

Windows Docker端口占用错误及解决方案总结

《WindowsDocker端口占用错误及解决方案总结》在Windows环境下使用Docker容器时,端口占用错误是开发和运维中常见且棘手的问题,本文将深入剖析该问题的成因,介绍如何通过查看端口分配... 目录引言Windows docker 端口占用错误及解决方案汇总端口冲突形成原因解析诊断当前端口情况解