静态和共享库符号冲突?

gct*_*gct 6 c++ linker

我有一个项目正在使用FreeImage和openCV,目前我们正在使用这两个方面的jpeg支持(我正在努力解决这个问题,但是现在它必须留下来).无论如何,FreeImage将libjpeg 7.0编译成静态库,而openCV的highgui库将它作为共享库链接(在我的系统上,Ubuntu 9,我已经安装了libjpeg 6.2).

它们链接到一个最终的库,用于链接到各种程序,java包装器等.所有这些工作正常,编译/链接时没有符号冲突或任何东西.但是,当我使用openCV cvLoadImage函数打开图像时,它会在读取标题时死亡,这很可能是由于6.2和7.0中标题之间的差异造成的.

如果我取消链接FreeImage(并注释掉需要它的代码),openCV调用再次开始工作,很明显FreeImage中的静态libjpeg符号与将从libjpeg共享库加载的符号冲突.我无法弄清楚的是为什么我的编译器在链接期间没有抛出错误,因为有两组libjpeg符号.另外,我已经尝试用7.0版本暂时替换我的系统的jpeglib.h头文件,看看openCV编译后是否会与freeimage带来的符号同步,似乎无济于事.

最后,我将一个printf放在libjpeg中的jpeg_read_header中,即freeimage编译,并重建它以查看openCV是否正在使用freeimage libjpeg定义.它没有打印出来所以我不得不假设.

所以我想我的问题是

1)为什么不链接静态libjpeg和共享libjpeg会因重复符号而产生链接错误?

2)有谁知道为什么这两件事彼此冲突?

编辑:在调试模式下编译openCV,然后在常规模式下再次编译似乎已经松动了一些东西并使其再次工作,不知道发生了什么.

Joh*_*ler 6

一般来说,链接器可以传递多个解析相同符号的库。它只使用它找到的第一个。链接器命令行上库的顺序将决定哪一个“获胜”。

顺便说一下,这不适用于目标文件。我曾经使用过的每个链接器都假定您使用您指定的所有对象,并且如果多个对象具有相同的符号,则会抱怨。


Any*_*orn 1

是这样的

静态库被编译,动态库在运行时加载,但只有那些丢失的符号(我认为)。您可以编译共享库,然后您可能会遇到符号冲突。

所以 opencv 使用编译的符号,因为它们已经存在,而不是来自动态库的符号。从 opencv 的角度来看,你最终会使用静态符号,可能具有不同的签名。