我的应用程序与静态初始化代码dlopens库。 所有其他的库都是一样的，之前加载好了，但是这个从另一个库调用函数的时候就死掉了。 这是这样的：
0x12311 <-- bad address _static_initialization_0 <-- function call .... dlopen 现在，反汇编中的函数调用看起来像
call _Z6MyFuncRA37_Kc@plt
然而，这个呼叫结束了呼叫无效地址0x12311，即PLT条目得到错误的地址。
问题是很有可能的，所讨论的图书馆是第三方的一种，即即使它依赖于其他图书馆来进入二进制预构buildforms。 上个星期我们做了一个很大的优化，并且改变了很多头文件等等。 PLT错误的函数MyFunc位于我们的（另一个）库中，得到了大量的优化更改。
这怎么可能？ 确切的问题是：
此外，同样的应用程序工作正常编译时使用-O2优化，这就是我所说的奇怪（二进制库在这两种情况下是相同的）。
PS的Ubuntu的12.04 x86_64，但应用程序是I386。
更新：build议在评论（删除由于某种原因）来检查LD_DEBUG是好的，在LD_DEBUG =绑定我看到这个在应用程序的“崩溃”版本：
10272: /media/EXT/work/build32/bin/libMyLib.so: error: symbol lookup error: undefined symbol: omp_set_num_threads (fatal)
然后它停止绑定libMyLib.so符号，而在非失败的版本中，它保持绑定其他符号。 但我不明白为什么然后继续执行，并尝试加载父库。 其实scheme如下：
libA -> libB -> libMyLib
libMyLib失败（如上面LD_DEBUG输出所示），所以它跳过它，也完全（！）libB，并继续绑定libA符号。 非失败版本完全加载libMyLib符号，然后继续使用libB符号，然后使用libA符号。
坦白地说，这看起来像ld错误。
至于为什么优化的版本工作，我想omp_方法是不是真的需要和链接器优化抛出，因此它不会在运行时find它。
这里是我看到LD_DEBUG =所有日志之后，找不到libC的omp_符号：
19225: symbol=omp_set_num_threads; lookup in file=/usr/lib/i386-linux-gnu/libXdmcp.so.6 [0] 19225: /media/EXT/Work/libC.so: error: symbol lookup error: undefined symbol: omp_set_num_threads (fatal) 19225: 19225: file=/media/EXT/libA.so [0]; destroying link map 19225: 19225: file=/media/EXT/libA.so [0]; dynamically loaded by /media/EXT/libX.so [0] 19225: file=/media/EXT/libA.so [0]; generating link map 19225: dynamic: 0xf2fdb764 base: 0xf2f81000 size: 0x00064a28 19225: entry: 0xf2f8ffd0 phdr: 0xf2f81034 phnum: 7 19225: 19225: checking for version `GCC_3.0' in file /lib/i386-linux-gnu/libgcc_s.so.1 [0] required by file /media/EXT/libA.so [0] ... few more checking 19225: object=/media/EXT/libA.so [0] 19225: scope 0: bin/mainapp /lib/i386-linux-gnu/libpthread.so.0 /media/EXT/libX.so ... 19225: scope 1:... 19225: 19225: 19225: relocation processing: /media/EXT/libA.so 19225: symbol=_ZTVN10__cxxabiv117__class_type_infoE; lookup in file=bin/mainapp [0] 19225: symbol=_ZTVN10__cxxabiv117__class_type_infoE; lookup in file=/lib/i386-linux-gnu/libpthread.so.0 [0] 19225: symbol=_ZTVN10__cxxabiv117__class_type_infoE; lookup in file=/media/EXT/libX.so [0] 19225: binding file /media/EXT/libA.so [0] to /media/EXT/libX.so [0]: normal symbol `_ZTVN10__cxxabiv117__class_type_infoE' ... here it continues to bind libA symbols, and after finishing that 19225: 19225: 19225: calling init: /media/EXT/libC.so 19225:
它调用init的非初始化libC.so模块。
（只是提到libX.so是调用dlopen的基本模块，也包含所有其他库使用的基本方法。）
在销毁libA的链接映射之后，日志显示它再次生成，我只是不明白装载器是否继续加载libA，或者这次从头开始，而不打扰libB / libC。 那么，在任何情况下，它都会忽略libB / libC，直到调用libC的init。
omp_set_num_threads与GCC内的OpenMP支持有关。
您可能应该在编译和链接时将-fopenmp标志传递给gcc（即使您只是使用OpenMP的库）。
也许原来的图书馆提供者忘记了。
（OpenMP正在改变编译过程的整个行为）