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

相关文章

SpringBoot+Docker+Graylog 如何让错误自动报警

《SpringBoot+Docker+Graylog如何让错误自动报警》SpringBoot默认使用SLF4J与Logback,支持多日志级别和配置方式,可输出到控制台、文件及远程服务器,集成ELK... 目录01 Spring Boot 默认日志框架解析02 Spring Boot 日志级别详解03 Sp

从入门到精通C++11 <chrono> 库特性

《从入门到精通C++11<chrono>库特性》chrono库是C++11中一个非常强大和实用的库,它为时间处理提供了丰富的功能和类型安全的接口,通过本文的介绍,我们了解了chrono库的基本概念... 目录一、引言1.1 为什么需要<chrono>库1.2<chrono>库的基本概念二、时间段(Durat

C++20管道运算符的实现示例

《C++20管道运算符的实现示例》本文简要介绍C++20管道运算符的使用与实现,文中通过示例代码介绍的非常详细,对大家的学习或者工作具有一定的参考学习价值,需要的朋友们下面随着小编来一起学习学习吧... 目录标准库的管道运算符使用自己实现类似的管道运算符我们不打算介绍太多,因为它实际属于c++20最为重要的

Visual Studio 2022 编译C++20代码的图文步骤

《VisualStudio2022编译C++20代码的图文步骤》在VisualStudio中启用C++20import功能,需设置语言标准为ISOC++20,开启扫描源查找模块依赖及实验性标... 默认创建Visual Studio桌面控制台项目代码包含C++20的import方法。右键项目的属性:

c++中的set容器介绍及操作大全

《c++中的set容器介绍及操作大全》:本文主要介绍c++中的set容器介绍及操作大全,本文通过实例代码给大家介绍的非常详细,对大家的学习或工作具有一定的参考借鉴价值,需要的朋友参考下吧... 目录​​一、核心特性​​️ ​​二、基本操作​​​​1. 初始化与赋值​​​​2. 增删查操作​​​​3. 遍历方

解析C++11 static_assert及与Boost库的关联从入门到精通

《解析C++11static_assert及与Boost库的关联从入门到精通》static_assert是C++中强大的编译时验证工具,它能够在编译阶段拦截不符合预期的类型或值,增强代码的健壮性,通... 目录一、背景知识:传统断言方法的局限性1.1 assert宏1.2 #error指令1.3 第三方解决

C++11委托构造函数和继承构造函数的实现

《C++11委托构造函数和继承构造函数的实现》C++引入了委托构造函数和继承构造函数这两个重要的特性,本文主要介绍了C++11委托构造函数和继承构造函数的实现,具有一定的参考价值,感兴趣的可以了解一下... 目录引言一、委托构造函数1.1 委托构造函数的定义与作用1.2 委托构造函数的语法1.3 委托构造函

C++11作用域枚举(Scoped Enums)的实现示例

《C++11作用域枚举(ScopedEnums)的实现示例》枚举类型是一种非常实用的工具,C++11标准引入了作用域枚举,也称为强类型枚举,本文主要介绍了C++11作用域枚举(ScopedEnums... 目录一、引言二、传统枚举类型的局限性2.1 命名空间污染2.2 整型提升问题2.3 类型转换问题三、C

C++链表的虚拟头节点实现细节及注意事项

《C++链表的虚拟头节点实现细节及注意事项》虚拟头节点是链表操作中极为实用的设计技巧,它通过在链表真实头部前添加一个特殊节点,有效简化边界条件处理,:本文主要介绍C++链表的虚拟头节点实现细节及注... 目录C++链表虚拟头节点(Dummy Head)一、虚拟头节点的本质与核心作用1. 定义2. 核心价值二

C++ 检测文件大小和文件传输的方法示例详解

《C++检测文件大小和文件传输的方法示例详解》文章介绍了在C/C++中获取文件大小的三种方法,推荐使用stat()函数,并详细说明了如何设计一次性发送压缩包的结构体及传输流程,包含CRC校验和自动解... 目录检测文件的大小✅ 方法一:使用 stat() 函数(推荐)✅ 用法示例:✅ 方法二:使用 fsee