C++又一坑:动态链接库中的全局变量
extern "C" {
void dll_func() {
foo_class::_.m += 100;
printf("&foo_class::_ = 0x%llx, foo_class::_.m = %d\n", &foo_class::_, foo_class::_.m);
}
}
編譯選項:
gcc -O0 -g -ggdb c.cpp -o libtest_c.so -shared -fPIC -L$PWD -ltest_a -lstdc++這是三個模塊的代碼和編譯選項。我分別至于Linux和Windows內的GCC編譯測試。
在Linux中的GCC 4.4.6 運行結果如下:
foo_class::foo_class(), this-> 0x600f98
&foo_class::_ = 0x600f98, foo_class::_.m = 1010
foo_class::foo_class(), this-> 0x600f98
&foo_class::_ = 0x600f98, foo_class::_.m = 110
foo_class::~foo_class(), this-> 0x600f98
foo_class::~foo_class(), this-> 0x600f98
從結果中可以看出來,在Linux中多個動態鏈接庫和主程序引用的同一個全局變量(地址相同),但是每一個二進制實例都會完成一次構造。這就造成了同一個實例多次構造,導致我們最初碰到的結果。
在Windows中Cygwin的GCC 4.8.2 中運行結果如下:
foo_class::foo_class(), this-> 0x100406010
&foo_class::_ = 0x100406010, foo_class::_.m = 1010
foo_class::foo_class(), this-> 0x5aa426010
&foo_class::_ = 0x5aa426010, foo_class::_.m = 110
foo_class::~foo_class(), this-> 0x5aa426010
foo_class::~foo_class(), this-> 0x100406010
但是在Windows中,雖然每個動態鏈接庫和主程序引用的同一個全局變量也各自都執行了一次構造。但是,每一個二進制內的全局變量,實際上并不是同一個。他們并不沖突,但是他們也不在一個內存區域內,所以即便是純C下和Linux內的行為也不一樣。
這也就意味著,在Linux中,載入的動態鏈接庫實際上可以直接使用外部框架或者其他模塊的全局數據,但是在Windows下確是隔離的,不能直接訪問到。
另外, 我從另一篇文章上看到,這個行為與dlopen時flag是RTLD_GLOBAL還是RTLD_LOCAL有關。但是我這里實測沒有任何變化。但是結果和編譯選項-fPIC有關(原因去看gcc文檔吧,我就不復述啦)。
PS: 如果不是直接使用的全局變量,而是直接使用函數接口,并且返回一個static的局部變量這種方式,測試結果也是一樣的;
而且如果不是通過dlopen動態加載,而是通過編譯時鏈接進去的話,也是構造了兩次。
這里就不再另外貼出輸出結果了。
其實,根本問題是多個動態鏈接庫里共享的內存對象的構造問題。在不同環境下有不同的行為,也許會藏地比較隱晦。著實是個坑吶。
總結
以上是生活随笔為你收集整理的C++又一坑:动态链接库中的全局变量的全部內容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: 共享库中的位置无关代码(PIC)
- 下一篇: jflash合并stm32f103之bi