這是Linux下的64位GCC 4.8.2。當從共享庫內部使用我的Qt插件時發現符號查找錯誤
我有由一個應用程序:
- 共享庫(以下稱爲CORE),應用程序的核心,它實現了大部分的邏輯,它也能處理我的加載自定義插件。
- 鏈接到核心CORE的可執行文件(以下稱爲EXEC)。它啓動了
QApplication
並使用了CORE的類,但它自己也增加了一些類。 - 自定義插件,基於Qt的插件框架(即他們實現純虛擬接口類,他們繼承
QObject
等)。所有插件都加載了QPluginLoaded
,它們正在工作。 插件加載由CORE中的類執行。
它可以表示或多或少是這樣的:
EXEC <- this I run
`- CORE.so <- this is dynamically linked with EXEC
+- plugin1.so <- those are loaded dynamically by QPluginLoader
+- plugin2.so
(...)
`- pluginN.so
問題:
它看起來像插件不能從EXEC使用任何符號,即使它們是由CORE裝,由EXEC加載。這是真的嗎?我認爲正在運行的應用程序在運行時將所有符號提供給任何加載的庫。
它編譯得很好,但在運行時,當插件使用EXEC中的任何符號時,應用程序崩潰並顯示消息:符號查找錯誤。
使用CORE符號沒有問題,只有EXEC符號不可用於插件。
我確定符號實現是編譯在 - 我已經做了幾個測試,用一個非常簡單的例子來避免任何複雜性。我也在午夜指揮官(F3鍵)檢查了符號,它在EXEC中。
編輯:我剛剛測試的情況下,QPluginLoader
創建它時,load()
直接從EXEC二進制中的main()
函數調用,它仍然不起作用。這就像來自CORE的符號以某種方式被「導出」,來自EXEC的符號不是......但這是Linux,沒有符號輸出,對吧?
因此,看起來在Linux下符號也被導出或不導出。共享庫的符號默認導出,可執行文件中的符號不是 - 這就解釋了我的問題。我會在今天晚些時候嘗試'-rdynamic',如果它有效,我會發佈一個答案。 – Googie
你使用qmake嗎? – lpapp
@Final_Contest:是的,爲什麼? – Googie