C 如何解决链接器库订单问题？

我试图编译一个需要使用几个库的C程序。问题是，库链接的顺序导致编译失败

有没有办法让GCC找出正确的顺序，或者让我找出正确的顺序而不必尝试所有的可能性

mipsel-linux-gcc ffmpeg_mips_test.c -o ffmpeg_mips_test -Wall -v -I/ffmpegMIPS/includeffmpegMIPS/
                 -L/ffmpegMIPS/libffmpegMIPS/ -lavformat -lavcodec -lavutil -lswscale -lm -lpthread

我目前的做法是从一个库开始，然后随着错误的发生添加更多的库，然而有时感觉像是在进步，有时似乎我遇到了死胡同

[edit]编译失败，因为未定义引用[/edit]

您有几个选项

1） 您可以向具有依赖项的库添加其他调用

2） 您可以这样使用

--start group/--end group

选项：

mipsel-linux-gcc ffmpeg_mips_test.c -o ffmpeg_mips_test -Wall -v -I/ffmpegMIPS/includeffmpegMIPS/
-L/ffmpegMIPS/libffmpegMIPS/ -Wl,--start-group -lavformat -lavcodec -lavutil -lswscale -Wl,--end-group -lm -lpthread

下面是描述其使用的

ld

手册页条目

将搜索指定的存档 重复，直到没有新的未定义 将创建引用。通常情况下 归档文件在中仅搜索一次 命令将其指定在 命令行。如果其中有一个符号 需要归档来解决问题 未定义的符号，由 出现的存档中的对象 稍后在命令行上，链接器 无法解决这个问题 参考通过对档案进行分组， 他们都被反复搜查，直到 所有可能的引用都已解决

---

不推荐使用

-lpthread

。您应该使用

-pthread

，gcc将生成pthread支持所需的任何选项和库

至于其他人，将它们按正确的顺序排列仅仅是理解它们之间的依赖关系的问题。如果

A

依赖于

B

，

-lA

应该出现在命令行的

-lB

之前。在您的例子中，

-lm

是系统数学库（出于愚蠢的遗留原因，它仅与主libc分离），不依赖于任何其他内容，因此它应该始终位于命令行的末尾

-lavutil

是由

ffmpeg

及其包含的库使用的实用函数库，因此它应该排在所有其他

ffmpeg

库之后

-lswscale

是一个图像缩放库，其他库可能需要它，因此我会将它放在

-lavformat

和

-lavcodec

之后，但在

-lavutil

之前，以防它需要

-lavutil

中的函数

最后，在

ffmpeg

世界中，编解码器被认为是基本的，容器被认为是它们上面的一层（而不是某些框架的反面），因此

-lavformat

依赖于

-lavcodec

。因此，示例中的最终顺序应为：

-lavformat -lavcodec -lswscale -lavutil -lm

并且

-pthread

可以在命令行中的任何位置运行；它通常会导致gcc在最后放置一个隐藏的

-lpthread

，但可能会在不同的系统上根据需要执行不同的操作