Question

我已经遇到了这个问题，我希望我能在这里找到一些帮助。我已经创建了一个小型示例可执行文件和共享库来展示问题。

很抱歉，我意识到这已经变成了一面文字，但我试图确保包含所有相关信息。

我的设置

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，看起来他们正在使用libc中的存根函数，因为pthread没有被链接。

我现在遇到的问题是尝试在pthread中链接以纠正上述问题。如果我使用pthreads构建，应用程序会尝试将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;
}

明确加载

尝试使用以下构建脚本在运行时加载共享库会导致尝试加载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 NEEDED并且依赖关系链中的所有库都没有libc.so.1作为依赖项。他们所依赖的libc版本是libc.so.6。

构建方案结束

我真的希望有人知道发生了什么，可以帮助我。我的Google和StackOverflow技能让我失望，因为我发现的所有内容都表明pthread使用不匹配是根本问题。

提前致谢！

Answer 1

${compiler} ${arch} -static -g -o main.out ./main.o -lpthread -ldl -lc

这是一个完全静态的链接。

在大多数操作系统上，不能从完全静态的二进制文件调用dlopen（dlopen根本没有在libdl.a中提供，并且链接失败。）

GLIBC是一个例外，但只有dlopen才能支持/etc/nsswitch.conf。几乎可以肯定，libpthread.so.0动态加载到包含其自己的a.out副本的完全静态libpthread.a中。简短的回答是：它会伤害，不要这样做。

在任何现代UNIX系统上，全静态链接通常都是一个非常糟糕的主意。多线程应用程序的完全静态链接是双重的。完全静态链接然后动态加载libpthread的另一个副本？真的坏主意。

<强>更新

GLIBC由许多库（200+）组成，我强烈建议不要为任何此类库混合静态和动态链接。换句话说，如果您链接到libc.a，请将其设为完全静态链接。如果您链接到libc.so，则不要静态链接libpthread.a，libdl.a或GLIBC的任何其他部分。

共享库和libpthread.so

1 个答案: