c++ - 从共享对象调用时 libmfx.a 中的 MFXInit() 出现段错误

Question

(虽然 Intel 的论坛是一个更自然的地方来提问 this question 我将它张贴在这里希望能有更多的事件，而不是 Intel 的完全缺乏 - 到目前为止)

我无法创建使用 Intel Media SDK(Linux 服务器)来操作 h264 视频的动态链接库，并注意到 MFX 库的设计存在问题。按照我的理解，程序应该链接到静态 库，例如:

$ g++ .... -L/opt/intel/mediasdk/lib/lin_x64 -lmfx

但是，这个libmfx.a 库似乎将所有调用委托(delegate)给一个dlopened dynamic 库/opt/intel/mediasdk/lib64/libmfxhw64.so。值得注意的是，静态库和动态库公开的函数名称(和签名)相同，这有点令人困惑和危险。

虽然我不明白这个设计背后的基本原理，但它本身不应该是一个问题，因为当(静态)libmfx.a 时，库内的一些静态/全局初始化显然会造成破坏 包含在共享对象中。即:

    +------+     +-----------+
    | main | <-- | mylib.so  |
    +------+     |           |          +---------------+
                 | libmfx.a  | (dlopen) | libmfxhw64.so |
                 |          <-------------              |
                 |+---------+|          |+-------------+|
                 ||MFXInit()||          ||  MFXInit()  ||
                 ||...      ||          ||  ...        ||
                 ||         ||          ||             ||
                 +===========+          +===============+

上面的库可以这样组装:

$ g++ -shared -o mylib.so my1.o my2.o -lmfx

然后(动态地)链接到 main.o，如下所示:

$ g++ -o main main.o mylib.so -ldl

(请注意，额外的 libdl 是允许 libmfx.a 到 dlopen() libmfxhw64.so.)

不幸的是，在第一次调用 MFXInit() 时，程序会导致段错误(访问地址 0x0000400)。 GDB 回溯:

#0  0x0000000000000400 in ?? ()
#1  0x00007ffff61fb4cd in MFXInit () from /opt/intel/mediasdk/lib64/libmfxhw64-p.so.1.13
#2  0x00007ffff7bd3a1f in MFX_DISP_HANDLE::LoadSelectedDLL(char const*, eMfxImplType, int, int) () from ./lib-a.so
#3  0x00007ffff7bd12b1 in MFXInit () from ./lib-a.so
#4  0x00007ffff7bd09c8 in test_mfx () at lib.c:12
#5  0x0000000000400744 in main (argc=1, argv=0x7fffffffe0d8) at main.c:8

(观察堆栈帧 #3 中的 MFXInit() 是 libmfx.a 中的那个，而 #1 中的那个 在 libmfxhw64.so 中。)

请注意，当 mylib 创建为静态 库时，不会 发生崩溃。使用断点和反汇编程序，我设法制作了以下回溯快照，在这两种情况下，#1 都位于 MFXInit+424，但它们似乎命中了不同 MFXQueryVersion 的版本(由于重定位，绝对地址无意义):

#0  0x00007ffff6411980 in MFXQueryVersion () from /opt/intel/mediasdk/lib64/libmfxhw64-p.so.1.13
#1  0x00007ffff640c4cd in MFXInit () from /opt/intel/mediasdk/lib64/libmfxhw64-p.so.1.13
#2  0x000000000040484f in MFX_DISP_HANDLE::LoadSelectedDLL(char const*, eMfxImplType, int, int) ()
#3  0x00000000004020e1 in MFXInit ()
#4  0x0000000000401800 in test_mfx () at lib.c:12
#5  0x0000000000401794 in main (argc=1, argv=0x7fffffffe0e8) at main.c:8

因为静态和共享英特尔库都公开了相同的 API 函数，所以我可以直接链接到 libmfxhw64.so 中，但我想绕过静态“调度程序” "没有保修(？)

有人可以解释英特尔在上述设计背后的想法吗？规范，为什么要提供一个只委托(delegate)给具有相同接口(interface)的 .so 的静态库？

此外，SEGV 似乎是由 libmfx.a 或 libmfxhw64.so 中的静态/全局数据引起的。有没有办法在动态加载的静态/全局部分上强制执行特定的执行顺序？调试此类问题的最佳方法是什么？

---

在 Intel Haswell i7-4790 @3.6Ghz 上使用 Intel Media SDK R2 (ubuntu 12) 和 Intel Media SDK 2015R3-R5 (Centos 7, 1.13/1.15) 测试

如果您有有效的英特尔 MSDK 设置，请编译 my example code确认问题。

Answer 1

在最近发布的调度程序源代码中，“readme-dispatcher-linux.pdf”文件的末尾是这样的:

There is slight difference between using Dispatcher library from executable module or from shared object. To mitigate symbol conflict between itself and SDK shared object on Linux*, application should: 1) link against libdispatch_shared.a instead of libmfx.a 2) define MFX_DISPATCHER_EXPOSED_PREFIX before any SDK includes

我用过这个，它可以解决你描述的符号冲突问题。

如果您安装“Intel Media Server Studio Professional 2016”，您可以找到这个文件。有一个免费的社区版。源文件和 PDF 位于/opt/intel/mediasdk/opensource/