鏈接庫C ++鏈接器的順序

Question

我正在調試一個項目，該項目依賴於一組庫，包括libfreenect，OpenGL和OpenCL。 問題是輸出是黑屏。

作為調試選項，我完全刪除了OpenCL代碼和鏈接庫，以確保OpenGL可以正常工作，而且幸運的是它可以正常工作。

我注意到但不了解的是，使用此庫順序，我的項目運行良好

 -lfreenect -lGL -lglut -lGLU -lOpenCL 

另一方面，使用此命令時會出現黑屏

-lfreenect -lOpenCL -lGL -lglut -lGLU

我的問題是：為什么鏈接庫的順序會影響程序的輸出？

Answer 1

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

嘗試在任一鏈接順序配置中對生成的程序二進制文件使用ldd ，並查看其實際引入的共享對象（在哪些路徑中）。

Answer 2

這樣想：

您已編譯了目標文件。 這些文件需要不存在的其他方法，並且在鏈接步驟中，您需要提供“覆蓋”所需方法的庫，以便可以創建一個簡潔的可執行文件。

對於您提供的每個庫，鏈接器都會對其進行處理，如果發現所需的方法，則使用它們。 然后，它重建缺少方法的表，並繼續使用包含的下一個庫。

如果您將OpenCL包含在第一個庫中，但是您的對象沒有直接調用OpenCL方法，則鏈接器將丟棄該庫。 之后，當您包含需要OpenCL的庫時，它將拋出“未定義的XXXXX方法”，因為該庫已被處理。 或者，就您而言，它可能會使用另一個內部庫，而該內部庫與您真正打算使用的內部庫不同。

一個好的規則是最后包含“基本”庫，以便它們在所有其他庫中使用。 在這種情況下，OpenCL不依賴任何GL庫，因此您應該最后添加它。