靜態和共享庫符號衝突？

我有一個項目正在使用FreeImage和openCV，目前我們正在使用這兩個jpeg支持（我正在努力解決這個問題，但現在它必須留下來）。無論如何，FreeImage將libjpeg 7.0編譯到它的靜態庫中，而openCV的highgui庫將它作爲共享庫（在我的系統上，Ubuntu 9，我已經安裝了libjpeg 6.2）鏈接它。靜態和共享庫符號衝突？

它們鏈接到一個最終的庫，用於鏈接到各種程序，java包裝等。所有這些工作正常，沒有符號衝突或任何在編譯/鏈接時間。但是，當我使用openCV cvLoadImage函數打開圖像時，它在讀取標題時就會消失，很可能是由於6.2和7.0中的標題之間的差異。

如果我取消FreeImage的鏈接（並註釋掉需要它的代碼），openCV調用會再次開始工作，因此FreeImage的靜態libjpeg符號與libjpeg共享庫中將要加載的符號衝突。我無法弄清楚爲什麼我的編譯器在鏈接過程中不會因爲兩組libjpeg符號而引發錯誤。另外，我試着用7.0版暫時替換我的系統的jpeglib.h頭文件，看看用它編譯的openCV是否會與freeimage帶給表格的符號同步，看起來無濟於事。

最後，我在jpeg_read_header中放置了freeimage編譯的libjpeg中的printf，並重新構建它以查看openCV是否使用freeimage libjpeg定義。它沒有打印出來，所以我不得不假設沒有。

所以我想我的問題是

1）爲什麼不鏈接一個靜態的libjpeg和共享的libjpeg生成鏈接因爲重複的符號錯誤？

2）有誰知道爲什麼這兩件事情彼此衝突？

編輯：在調試模式下編譯openCV，然後在常規模式下似乎再次鬆動並重新工作，不知道發生了什麼。

來源

2010-02-07 Sean McAllister

就是這個樣子

靜態庫編譯，動態庫在運行時加載，但只有那些符號被丟失（我認爲）。你可以編譯共享庫，然後你可能會遇到符號衝突。

因此，opencv使用已編譯的符號，因爲它們已經存在，而不是來自動態庫的符號。你最終會使用靜態符號，可能有不同的簽名，來自opencv的預期。

來源

2010-02-07 06:59:12 Anycorn

我的假設是，它正在使用一個或其他庫，但也許它使用了一點兩種？更改openCV編譯的頭文件並沒有解決問題。 – 2010-02-07 17:01:58

一般來說，鏈接器可以傳遞所有解析相同符號的多個庫。它只是使用它找到的第一個。鏈接器命令行上庫的順序將決定哪一個「獲勝」。

順便說一句，這是不正確的對象文件。我曾經使用過的每一個鏈接器都假設你想要使用你指定的所有對象，並且如果多於一個具有相同的符號，就會抱怨。

來源

2010-02-07 07:05:36

因此，最有可能的是，libjpeg的一個或另一個版本會「贏」嗎？所以要麼選擇openCV版本，在這種情況下，事情會起作用，或者在編譯期間將openCV使用的頭部切換到freeimage，應該修復它...但它不= =（ – 2010-02-07 17:09:56

如果鏈接器選擇的那個是不同於你使用的頭文件，那麼我會期望它不工作，你需要切換頭文件_並且還要重新排列鏈接線上的庫文件，甚至是求偶失敗，最好是把你不想要的庫文件完全使用鏈接線 – 2010-02-07 20:02:14

您需要修改鏈接選項才能導出所需的符號，然後衝突中的所有符號都將在靜態鏈接的內部隱藏，然後不會發生衝突。默認情況下所有符號都被導出，這就是問題所在。看到這個鏈接：http://www.gnu.org/software/gnulib/manual/html_node/Exported-Symbols-of-Shared-Libraries.html

來源

2010-05-28 11:31:42

靜態和共享庫符號衝突？

回答

相關問題