• <ins id="pjuwb"></ins>
    <blockquote id="pjuwb"><pre id="pjuwb"></pre></blockquote>
    <noscript id="pjuwb"></noscript>
          <sup id="pjuwb"><pre id="pjuwb"></pre></sup>
            <dd id="pjuwb"></dd>
            <abbr id="pjuwb"></abbr>

            Prayer

            在一般中尋求卓越
            posts - 1256, comments - 190, trackbacks - 0, articles - 0
              C++博客 :: 首頁 :: 新隨筆 :: 聯系 :: 聚合  :: 管理

            問題

            最近項目遇到一些問題,場景如下

            主程序依賴了兩個庫libA的funcA函數和libB的funcB函數。示意的代碼(main.cpp)如下:

            #include <cstdio>  int funcA(int, int); int funcB(int, int);  int main() {     printf("%d,", funcA(2, 1));     printf("%d\n", funcB(2, 1));     return 0; }

            libA示意實現(libA.cpp)如下:

            int subfunc(int a, int b) {     return a + b; }  int funcA(int a, int b) {     return subfunc(a, b); }

            libB示意實現(libB.cpp)如下:

            int subfunc(int a, int b) {     return a - b; }  int funcB(int a, int b) {     return subfunc(a, b); }

            可見funcA調用了libA中的內部函數subfunc,funcB調用了libB中的內部函數subfunc,這兩個subfunc實現不同,但不幸的是名字不小心起得一樣了

            這時我們嘗試編譯并運行:

            g++ -fPIC libA.cpp -shared -o libA.so g++ -fPIC libB.cpp -shared -o libB.so  g++ main.cpp libA.so libB.so -o main  export LD_LIBRARY_PATH=. ./main

            我們期望的結果是3,1(funcA和funcB各自調用不同的subfunc實現),

            實際得到的結果是3,3(funcA和funcB都調用了libA中的subfunc實現)

            原因

            我們通過readelf來查看符號:

            $ readelf -a libA.so | grep subfunc 000000200a60  000200000007 R_X86_64_JUMP_SLO 0000000000000708 _Z7subfuncii + 0      2: 0000000000000708    20 FUNC    GLOBAL DEFAULT   10 _Z7subfuncii     45: 0000000000000708    20 FUNC    GLOBAL DEFAULT   10 _Z7subfuncii  $ readelf -a libB.so | grep subfunc  000000200a60  000200000007 R_X86_64_JUMP_SLO 0000000000000708 _Z7subfuncii + 0      2: 0000000000000708    22 FUNC    GLOBAL DEFAULT   10 _Z7subfuncii     45: 0000000000000708    22 FUNC    GLOBAL DEFAULT   10 _Z7subfuncii

            可見libA和libB里面都有subfunc符號,名字完全一樣,而且都是GLOBAL的

            GLOBAL的符號即全局的符號,同名的全局符號會被認為是同一個符號,由于main先加載了libA,得到了libA中的subfunc符號,再加載libB時,就把libB中的subfunc忽略了。

            解決方案

            這其實是符號的可見性(Symbol Visibility)問題,既然有GLOBAL符號,那自然會有LOCAL符號,LOCAL的符號只在當前lib可見,全局不可見。

            如何將符號變成LOCAL的呢,最直接的就是加上visibility為hidden的標志,修改后的libA.cpp:

            __attribute__ ((visibility ("hidden"))) int subfunc(int a, int b) {     return a + b; }  int funcA(int a, int b) {     return subfunc(a, b); }

            再重新編譯執行,可以得到結果為3,1,成功!這里再查看一下libA的符號:

            $ readelf -a libA.so | grep subfunc     40: 00000000000006a8    20 FUNC LOCAL DEFAULT 10 _Z7subfuncii

            可見subfunc符號已經變成了LOCAL

            默認LOCAL

            上面的方法可以解決問題,但是,實際情況往往是,libA里面有很多的內部函數,而暴露給外部的只有少數,能不能指定少數符號為GLOBAL,其它的都是LOCAL呢?答案是肯定的,修改libA.cpp如下:

            int subfunc(int a, int b) {     return a + b; }  __attribute__ ((visibility ("default"))) int funcA(int a, int b) {     return subfunc(a, b); }

            這時,libA的編譯參數需要加上-fvisibility=hidden:

            g++ -fPIC libA.cpp -shared -fvisibility=hidden -o libA.so

            同樣可以解決問題。

            跨平臺兼容性

            windows平臺對于符號的行為是不一樣的,windows默認動態庫里符號是LOCAL的,通過__declspec(dllexport)來聲明GLOBAL符號,所以可以用下面的方式來兼容:

            #if defined _WIN32 || defined __CYGWIN__   #ifdef BUILDING_DLL     #ifdef __GNUC__       #define DLL_PUBLIC __attribute__ ((dllexport))     #else       #define DLL_PUBLIC __declspec(dllexport) // Note: actually gcc seems to also supports this syntax.     #endif   #else     #ifdef __GNUC__       #define DLL_PUBLIC __attribute__ ((dllimport))     #else       #define DLL_PUBLIC __declspec(dllimport) // Note: actually gcc seems to also supports this syntax.     #endif   #endif   #define DLL_LOCAL #else   #if __GNUC__ >= 4     #define DLL_PUBLIC __attribute__ ((visibility ("default")))     #define DLL_LOCAL  __attribute__ ((visibility ("hidden")))   #else     #define DLL_PUBLIC     #define DLL_LOCAL   #endif #endif

            隱藏外部依賴的符號

            我遇到的實際情況比上面更復雜一些,subfunc并不是在libA中實現的,而是在另一個外部庫libsubfunc.a中實現的。libA通過包含頭文件來獲取到這個函數:

            #include "subfunc.h"  int funcA(int a, int b) {     return subfunc(a, b); }

            上面的-fvisibility僅對實現生效,不能對聲明生效。但libsubfunc.a是第三方庫,我們不能去改它的代碼,也不能改它的頭文件,對于這種情況,gcc提供了下面方式來支持:

            #pragma GCC visibility push(hidden) #include "subfunc.h" #pragma GCC visibility pop  int funcA(int a, int b) {     return subfunc(a, b); }

            這種方式更方便靈活。

            如果是dlopen載入so可以通過參數控制。

            久久人妻少妇嫩草AV蜜桃| 久久久久四虎国产精品| 国产激情久久久久久熟女老人| 日韩欧美亚洲综合久久 | 久久99精品久久久久久久久久| 97久久精品午夜一区二区| 久久久久久一区国产精品| 中文字幕久久波多野结衣av| 久久久青草青青国产亚洲免观| 性欧美丰满熟妇XXXX性久久久| 久久久久亚洲AV成人网| 无码精品久久久天天影视| 久久久久国产| 热99re久久国超精品首页| 区久久AAA片69亚洲| 三级韩国一区久久二区综合| 国产精品久久久久影院色| 中文字幕日本人妻久久久免费| 国产精品久久波多野结衣| 精品国产青草久久久久福利| 日本高清无卡码一区二区久久| av午夜福利一片免费看久久 | 久久无码人妻一区二区三区午夜| 久久国产精品二国产精品| 91精品国产综合久久精品| A级毛片无码久久精品免费| 欧美激情精品久久久久久久九九九| 久久精品成人国产午夜| 久久精品国产网红主播| 久久国产精品99国产精| 亚洲日韩中文无码久久| 国产精品久久久久久五月尺| 亚洲国产成人久久综合野外| 午夜精品久久久久久久无码| 久久99国产精品成人欧美| 国产福利电影一区二区三区,免费久久久久久久精 | 伊人久久大香线蕉AV一区二区| 热99re久久国超精品首页| www亚洲欲色成人久久精品| 国内精品久久久久久麻豆| 精品久久久无码中文字幕|