AIX/LINUX下共享库中全局变量构造顺序差异问题？

luckysym

大致情况是这样，一个程序包含一个可执行的app和两个so库，依赖关系是app依赖liba.so，liba依赖libb.so(app-->liba -->libb).
liba中有一个类A的全局变量g_a, 构造函数中输出一条消息“class A init”，
同样，libb中有一个类B的全局变量g_b，构造函数中输出一条“class B init”

在AIX下编译后执行输出:
class A init
class B init

而在LINUX下执行收输出
class B init
class A init

按理说，被依赖的库应该优先初始化，LINUX的结果应该是符合预期的。
但是AIX下顺序颠倒了，导致LIBA初始化过程中依赖LIBB的部分失败。

本人对AIX不太熟悉，希望有大师给指点一下，
如何能够使AIX在初始化共享库依赖时的行为，和LINUX一致。

流氓无产者

不太了解，估计跟编译器有关
aix下是使用gcc toochains么？
如果是，那么只有改成显式初始化，这个才能由你控制

luckysym

回复 2# 流氓无产者

xlc, 就是因为要用xlc，所有掉坑里不知道怎么爬出来。。。

   

folklore

向IBM报Bug噬~~~


然而有一条规则是：　SO初始化中不能Load另一个SO。所以，最好你改改自已的代码。

luckysym

回复 4# folklore


    哦，难道一个SO不能依赖另一个SO? 那一个SO要调用另一个SO的的函数怎么办？

folklore

一个SO可以依赖另一个SO，请见上面帖子中的
"初始化中"

luckysym

回复 6# folklore


    没有在初始化时做dlopen，依赖关系在编译链接时就定了。库加载应该在进程初始化是自动干的。

folklore

如果一个so有全局类实例，那这个全局类的初始化（Constructor）中不能依赖另一个SO。

wlmqgzm

我猜一个办法, 也许可行,  就是全局变量中定义为   std::shard_ptr<T>  sp_t;
在main中,再初始化,  sp_t=std::make_shared_ptr<T>(.....),
这样就把初始化放到最后的环节来实现了, 是否就没有这个问题了.