linux 动态库构造函数,Linux共享库全局构造函数的相互依赖性

操作系统Centos 5.6 i686 2.6.18-53.1.4.el5vm.

gcc版本4.1.2 20080704(Red Hat 4.1.2-48)

ld版本2.17.50.0.6-6.el5 20061020

我以这种方式编译：

gcc -c -fnon-call-exceptions -fexceptions -Wall -DUNICODE -D_UNICODE -D_REENTRANT -I.

并以这种方式链接：

gcc -lstdc -pthread -ldl -lrt –no-relocate -Wl,-rpath,$SO_DIR -L $SO_DIR $LIBRARIES

我有3个库和一个可执行文件：A.so,B.so,C.so,ElfExec

B.so取决于A.so.

C.so取决于B.so.

在代码A.so中具有通过其公开功能A.h的标头,在代码中B.so具有B.h标头,其中包括A.h和B的功能.代码中的C.so包括B.h.

A.h定义了一个静态变量K,该类型可以在且仅当初始化A.so的静态内存管理器时使用.变量K在头文件A.h中直接定义,因此,它的初始化在组成B.so和C.so的所有对象的全局构造函数中传播.

我像这样链接所有内容：

gcc“所有B模块” -lstdc -pthread -ldl -lrt –no-relocate -Wl,-rpath,$SO_DIR -L $SO_DIR A.so

gcc“所有C模块” -lstdc -pthread -ldl -lrt-无重定位-Wl,-rpath,$SO_DIR -L $SO_DIR B.so

gcc“所有ElfExec模块” -lstdc -pthread -ldl -lrt –no-relocate -Wl,-rpath,$SO_DIR -L $SO_DIR C.so

我也尝试过：

gcc“所有ElfExec模块” -lstdc -pthread -ldl -lrt –no-relocate -Wl,-rpath,$SO_DIR -L $SO_DIR A.so B.so C.so

ElfExec在运行时会收到SIGSEGV,因为它会在初始化A.so的静态内存管理器之前尝试初始化变量K.

这是因为C.so的全局构造函数在A.so的全局构造函数之前被调用.

如果我制作只需要B.so的应用程序ElfExec2

gcc“所有ElfExec1模块” -lstdc -pthread -ldl -lrt –no-relocate -Wl,-rpath,$SO_DIR -L $SO_DIR B.so

这正常工作.

对于ElfExec1,链接器看到需要先调用A.so中的全局构造函数,然后再调用B.so中的全局构造函数.

在ElfExec的情况下,这不会受到限制.

我的解决方案是这样链接C.so：

gcc“所有C模块” -lstdc -pthread -ldl -lrt –no-relocate -Wl,-rpath,$SO_DIR -L $SO_DIR A.so B.so

这使C.so与A.so直接相关.

还有另一种方式可以告诉链接程序全局构造函数调用的顺序吗？

解决方法:

如您所见,不要相信链接器比您更了解.如果顺序很重要,则需要以编程方式指定顺序.不要只是试图欺骗链接器.

如果这些不是库,那就是您要做的,对吧？以正确的顺序互相调用的构造函数/初始化函数？

我的第一选择是将库设计为不具有或使用全局变量.

如果您不能这样做,那么我的第二个选择是为每个需要初始化全局变量以具有init方法的库.库的使用者需要先调用该init方法,然后才能执行任何操作,并且库必须尝试阻止使用/构造,直到正确完成init为止.也许将它们静态化为init方法,然后设置指向它们的全局指针(K * k)可能有助于实现.这应该足以使初始化链以正确的顺序组合在一起.

最后,如果让任何库的用户(对于A表示B,对于C表示B,对于C而言,C)的用户都遇到障碍,则可以对gcc使用如下语言扩展：

extern "C" __attribute__ ((constructor)) void A_lib_ctor()

{

// ....

}

extern "C" __attribute__ ((destructor)) void A_lib_dtor()

{

// ....

}

在加载库时自动执行所需的操作.这牺牲了一些可移植性.可能会牺牲更多,较新版本的gcc支持构造函数(优先级)语法.

我的最后选择是使用dlopen手动加载库的复杂步骤.

对于您而言,最重要的选择是设计更好,而后来的选择则更糟.