2015-06-16 127 views
0

我正在調試一個項目,該項目依賴於一組庫,包括libfreenect,OpenGL和OpenCL。問題在於黑屏是輸出。鏈接庫的順序C++鏈接器

作爲一個調試選項,我已經刪除了OpenCL代碼和鏈接庫,完全試圖確保OpenGL正常工作,幸運的是它的確如此。

我已經注意到了,不明白的是,我的項目工程,並使用圖書館

-lfreenect -lGL -lglut -lGLU -lOpenCL 

在另一方面這個命令很好,黑屏給出在使用這個命令

-lfreenect -lOpenCL -lGL -lglut -lGLU

我的問題是:爲什麼鏈接庫的順序會影響程序的輸出?

+0

你的問題是什麼? – n0rd

+2

發佈受訂單影響的源代碼片段。根據您提供的信息量很難得出結論。 – Barracuda

+1

如果兩個庫包含相同的入口點,它將使用找到的第一個入口點,它將是第一個指定的庫。我懷疑OpenCL和GL可能在你的系統上有共同的入口點。順便說一下,所有這些訂單看起來都有問題。 '-lglut'和'-lGLU'應該總是在'-lGL'之前。 –

回答

3

安裝在您的系統上的OpenCL接口庫可能會引入與最終將由您的程序加載的libGL.so不同的libGL.so。例如,如果您已經安裝了Mesa OpenCL實現,但正在使用NVidia驅動程序,那麼與Mesa的OpenCL鏈接可能會將Mesa的libGL與OpenGL在您的系統上運行所需的libGL衝突;當然這只是猜測。

嘗試在任一環節訂單配置生產的程序二進制使用ldd,看看哪些共享對象(其中路徑)它的實際拉動

+0

太棒了,這正是我的情況。也謝謝你的提示。 –

1

考慮一下這種方式:

你有你的對象編譯的文件。這些文件需要額外的方法,而這些方法並不存在,並且在鏈接步驟中,您需要提供「覆蓋」所需方法的庫,以便它可以創建一個簡潔的可執行文件。

對於您提供的每個庫,鏈接器都會接受它,對其進行處理,如果它找到需要的方法,則使用它們。 然後它重建丟失的方法表,並繼續包含下一個庫。

如果您將OpenCL包含在第一個庫中,但您的工程不直接調用OpenCL方法,則鏈接器將放棄該庫。 稍後,當您包含需要OpenCL的庫時,它將拋出一個「未定義的XXXXX方法」,因爲該庫已經被處理。 或者,您的情況可能會使用與您真正打算使用的庫不同的另一個內部庫。

一個很好的規則是最後包含「基本」庫,以便它們可以在所有其他庫中使用。在這種情況下,OpenCL不依賴任何GL庫,所以應該最後添加它。