我在这个问题上碰壁了,希望在这里能找到一些帮助.我创建了一个小示例可执行文件和共享库来展示该问题.
抱歉,我意识到这变成了文字墙,但是我试图确保包含所有相关信息.
我的设定
System: CentOS release 5.11 (Final)
g++: gcc version 4.4.7 20120313 (Red Hat 4.4.7-1) (GCC)
libc.so.6: Compiled by GNU CC version 4.1.2 20080704 (Red Hat 4.1.2-55).
我也曾在Redhat 6.6机器上尝试过类似的结果.
我的情况:
我有一个应用程序正在尝试通过:: dlopen()在运行时加载共享库.如果我不链接pthread,那么它似乎可以工作,但最终会在共享库中崩溃,并尝试引发异常.这样做的原因是,系统运行时库是在期望线程本地存储(TLS)的情况下构建的,并且异常处理使用了TLS中的数据结构,但在这种情况下,该数据结构为NULL并导致崩溃.这些函数是__cxa_allocate_exception和__cxa_get_globals,并且由于未链接pthread,因此它们似乎正在使用libc中的存根函数.
我现在遇到的问题是尝试在pthread中进行链接以更正上述问题.如果我使用pthreads进行构建,则应用程序segfaults尝试加载libpthread.so.0作为我的共享库的依赖项.我所读到的有关此崩溃的所有信息是,应用程序是在没有pthread的情况下构建的,而共享库是在pthread的情况下构建的.但是,我正在使用pthreads构建两个二进制文件,但仍然遇到问题.
样例代码:
共享库文件(foo.*)
foo.h
#pragma once
extern "C"
{
extern void DoWork();
}
foo.cpp
#include "foo.h"
#include <stdio.h>
void DoWork()
{
printf( "SharedLibrary::DoWork()\n" );
}
应用程序文件(main.cpp)
main.cpp
#include "foo.h"
#include <stdio.h>
#include <dlfcn.h>
void LoadSharedLibrary()
{
void* handle = 0;
void(*function)();
try
{
printf( "Loading the shared library\n" );
handle = ::dlopen( "libfoo.so", 2 );
function = (void (*)())::dlsym( handle, "DoWork" );
printf( "Done loading the shared library\n" );
function();
}
catch(...)
{
printf( "ERROR - Exception while trying to load the shared library\n" );
}
}
int main(int argc, char* argv[])
{
LoadSharedLibrary();
return 0;
}
显式加载
尝试使用以下构建脚本在运行时加载共享库会导致segfault尝试加载libpthread.so.0.
构建脚本:
compiler=g++
arch=-m32
echo gcc architecture flag: ${arch}
${compiler} -c -fPIC -g ${arch} -pthread -o ./foo.o foo.cpp
${compiler} ${arch} -shared -g -o ./libfoo.so ./foo.o -lpthread
${compiler} -c -fPIC -g ${arch} -pthread -o ./main.o main.cpp
${compiler} ${arch} -static -g -o main.out ./main.o -lpthread -ldl -lc
此崩溃的堆栈跟踪为:
#0 0x00000000 in ?? ()
#1 0x0089a70a in __pthread_initialize_minimal_internal () at init.c:417
#2 0x0089a218 in call_initialize_minimal () from /lib/libpthread.so.0
#3 0x00899da8 in _init () from /lib/libpthread.so.0
#4 0x0808909b in call_init ()
#5 0x080891b0 in _dl_init ()
#6 0x08063a87 in dl_open_worker ()
#7 0x0806245a in _dl_catch_error ()
#8 0x0806349e in _dl_open ()
#9 0x08053106 in dlopen_doit ()
#10 0x0806245a in _dl_catch_error ()
#11 0x08053541 in _dlerror_run ()
#12 0x08053075 in __dlopen ()
#13 0x0804830f in dlopen ()
#14 0x0804824f in LoadSharedLibrary () at main.cpp:13
#15 0x080482d3 in main (argc=1, argv=0xffffd3e4) at main.cpp:27
加载的共享库是:
From To Syms Read Shared Object Library
0xf7ffb3b0 0xf7ffb508 Yes libfoo.so
0x0089a210 0x008a5bc4 Yes (*) /lib/libpthread.so.0
0xf7f43670 0xf7fbec24 Yes (*) /usr/lib/libstdc++.so.6
0x009a8410 0x009c35a4 Yes (*) /lib/libm.so.6
0xf7efb660 0xf7f02f34 Yes (*) /lib/libgcc_s.so.1
0x0074dcc0 0x0084caa0 Yes (*) /lib/libc.so.6
0x007197f0 0x0072f12f Yes (*) /lib/ld-linux.so.2
(*): Shared library is missing debugging information.
隐式加载
这使用了一个不同的构建脚本,该脚本尝试在构建时设置依赖性,并且从理论上讲不需要显式的加载调用.对于我们的实际情况来说,这不是一个有效的用例,但是我在研究此问题时尝试这样做.
构建脚本:
compiler=g++
arch=-m32
echo gcc architecture flag: ${arch}
${compiler} -c -fPIC -g ${arch} -pthread -o ./foo.o foo.cpp
${compiler} ${arch} -shared -g -o ./libfoo.so ./foo.o -lpthread
${compiler} -c -fPIC -g ${arch} -pthread -o ./main.o main.cpp
${compiler} ${arch} -static -g -L. -o main.out ./main.o -lpthread -ldl -Wl,-Bdynamic -lfoo -Wl,-static -lc
行为:
Starting program: /app_local/dev3/stack_overflow/main.out
/bin/bash: /app_local/dev3/stack_overflow/main.out: /usr/lib/libc.so.1: bad ELF interpreter: No such file or directory
/bin/bash: /app_local/dev3/stack_overflow/main.out: Success
在启动期间,程序以代码1退出.
奇怪的是我已经完成了objdump -p< library> |需要grep,并且依赖项链中的所有库都没有libc.so.1作为依赖项.他们依赖的libc版本是libc.so.6.
构建方案结束
我真的希望这里的人对发生的事情有所了解,可以对我有所帮助.我的Google和*技能使我失败了,因为我发现的所有问题都表明不匹配的pthread使用是根本问题.
提前致谢!
解决方法:
${compiler} ${arch} -static -g -o main.out ./main.o -lpthread -ldl -lc
这是一个完全静态的链接.
在大多数操作系统上,无法从完全静态的二进制文件调用dlopen(libdl.a中根本没有提供dlopen,并且链接失败).
GLIBC是一个例外,但仅在支持/etc/nsswitch.conf时才需要dlopen.几乎可以肯定,不支持将libpthread.so.0动态加载到包含其自己的libpthread.a副本的全静态a.out中.简短的答案是:很痛,不要那样做.
在任何现代UNIX系统上,全静态链接通常是一个非常糟糕的主意.双线程应用程序的全静态链接是双重的.全静态链接然后动态加载libpthread的另一个副本?真是个坏主意.
更新:
GLIBC由许多库(200)组成,我强烈建议不要为任何此类库混合使用静态和动态链接.换句话说,如果链接到libc.a,则使其成为一个完全静态的链接.如果链接到libc.so,则不要静态链接libpthread.a,libdl.a或GLIBC的任何其他部分.