1. 首頁
  2. 問答
  3. 檢測/避免g ++符號衝突

檢測/避免g ++符號衝突

2010-02-10 99 views
1

如果兩個共享庫都暴露相同的全局範圍符號，是否有檢測和避免的方法？我們最近遇到了一個情況，我們有libA.so導出SuperCoolMethod()和libB.so也暴露了SuperCoolMethod()這將打破上述方法的前一個副本。這是在使用g ++ 4.0及更高版本的Linux上。所以隔離如果你鏈接到libA.so一切都會按預期工作，但一旦libB.so被添加到圖片中，調用了錯誤的方法，調用會失敗，導致正在執行的線程中止，而不通知我們潛在的問題。通過耗盡試驗和錯誤，我們最終發現SuperCoolMethod()得到了破壞，並通知了供應商libB.so，以便__attribute__((visibility("hidden")))可以應用到他們的方法副本。檢測/避免g ++符號衝突

來源

2010-02-10 Steven Behnke

回答

0

動態加載庫和通過dlopen和dlsym附加符號將工作。你將不得不編寫代碼才能做到這一點，但如果你真的被卡住了，這將是一個解決方案

來源

2010-02-10 02:01:15 pm100

+0

嗯，這可能工作，因爲我們從來沒有使用需要顯式調用有問題的函數，但它並沒有告訴我如何發現衝突開始。 – 2010-02-10 02:40:56

+0

nm和grep的組合會告訴你 – pm100 2010-02-10 18:05:21

1

因爲這是C++庫，每個庫都應該在它們自己的命名空間中，所以不會發生衝突。

來源

2010-02-10 02:09:23 Mark

+0

應該適用於，但不適用於第三方供應商。 – 2010-02-10 02:39:17

+1

如果您可以「通知libB.so的供應商，以便__attribute（（visibility（」hidden「））」「您可以要求可以在非gnu編譯器上工作的命名空間 – Mark 2010-02-10 13:21:54

0

作爲解決方法，如果您只使用這兩種方法中的一種，則它們在鏈接命令行上出現的順序決定了最終可執行文件中最終使用的函數版本。

這不只是一個神器，它的定義行爲，所以你可以依賴它（直到供應商修復它）。

來源

2010-02-10 05:01:25

相關問題

 相關問題