正確鏈接Ubuntu中的GLX庫

-2

我想編譯X11 + OpenGL的這些混合之一，但我沒有運行編譯器。特別是，我得到：正確鏈接Ubuntu中的GLX庫

undefined symbol: glXMakeCurrent

我已經試過

-lX11 -lGLU -lGL -lXext

作爲參數傳遞給鏈接器，以及它們的一些排列，沒有運氣這麼遠。

我正在運行Ubuntu 12.04，並且我已經安裝了所有與opengl相關的開發包，我有一個模糊的想法可能是相關的。我也在用C++進行開發，如果opengl頭文件沒有準備好，可能會導致問題......但它們是正確的？

我甚至在/ usr/lib/x86_64-linux-gnu /中用fgrep顯式地查找了符號，但它不在那裏，而且`nm'表示沒有符號。

那麼，與glx鏈接的正確方法是什麼？

編輯：這是鏈接的問題，當python試圖加載編譯（和錯誤鏈接）模塊時產生的錯誤。不在編譯時。

編輯：這裏是編譯日誌

scons: Reading SConscript files ... 
    scons: done reading SConscript files. 
    scons: Building targets ... 
    g++ -o build/debug/objects/alve/layouter/flowing_data.os -c -std=c++0x -g -I/usr  /include/python2.7 -fPIC -I/opt/cairo_new/include/cairo/ -I/opt/boost_1_48_0/include -DMIC_RT_SPEED_BACKS -Icsrc csrc/alve/layouter/flowing_data.cpp 
    g++ -o build/debug/objects/alve/layouter/liblayouter.so -L/opt/cairo_new/lib -L/opt/boost_1_48_0/lib -shared build/debug/objects/alve/layouter/flowing_data.os build/debug/objects/alve/layouter/show_network.os -Lbuild/debug/lib -Llibdeps 
    Install file: "build/debug/objects/alve/layouter/liblayouter.so" as "build/debug/lib/liblayouter.so" 
    g++ -o build/debug/objects/alve/layouter/liblayouter_mod.so -L/opt/cairo_new/lib -L/opt/boost_1_48_0/lib -shared build/debug/objects/alve/layouter/module.os Lbuild/debug/lib -Llibdeps -lboost_python build/debug/objects/alve/layouter/liblayouter.so -lcairo -lX11 -lGL -lGLU -lXext 
    scons: done building targets.

，這裏是該函數的調用：

glXMakeCurrent (dpy, win, ctx);

來源

2012-10-23 dsign

這個問題缺乏重要信息，就像清楚地指出這是針對Python導入模塊。所需信息：源代碼大綱，構建配置（Makefile或類似），**編譯器**標誌和全套鏈接器標誌。 – datenwolf

@datenwolf我的問題是「什麼是正確的方式鏈接反對glx在Linux中......」如果答案需要整個世界作爲參數...以及我會在這種情況下標記它「哈斯克爾」。 – dsign

鏈接GLX的正確方法是將libGL.so添加到您的鏈接庫集 - 您已經完成了 - 如Linux OpenGL ABI（可在OpenGL網站上找到）中所述。但編譯後的二進制文件會動態鏈接到另一個程序中，因此必須採取特殊的預防措施。哪些取決於目標程序。 – datenwolf

消息「未定義的符號」表示，這不是一個鏈接器，但編譯單元問題：編譯器不知道符號glXMakeCurrent，因爲它既沒有聲明也沒有定義，但是使用它。

GLX頭可能沒有被包括在內。

添加

#include <GL/glx.h>

事實證明OP的問題是相關的事實，即構建包括級聯形成一個Python模塊的共享對象。一個共享對象實現了實際的OpenGL操作，另一個共享對象與Python解釋器連接。

現在共享對象（.so）是完全合格的ELF二進制文件，每個都有自己的導入和導出符號表。共享對象可以配置爲公開其鏈接到的其他共享對象的所有符號。然而，共享對象不會看到它們鏈接到的編譯單元的任何符號（如果您仔細考慮它，這是可以預料的，因爲共享對象不能也不應該對它將要進行的環境做出任何假設鏈接到）。

因此，在編譯和鏈接多個共享對象時，將每個共享對象單獨鏈接到運行時所需的任何庫是很重要的。

來源

2012-10-23 09:48:29 datenwolf

這是一個鏈接器問題。編譯運行完美，甚至連接，爲python生成擴展模塊...當連接模塊dyn時出現問題。 – dsign

另外，我的g ++通常會說「'這個東西'沒有在這個範圍中聲明」，用於未聲明的符號。 – dsign

@dsign：這是您原始問題丟失的重要信息。您既沒有告訴我們您正在嘗試創建Python模塊，也沒有在嘗試加載模塊時發生錯誤。 Python通過dlopen加載模塊，在這種情況下，某些事情的工作方式會非常不同。你的問題仍然遺漏了重要的信息，比如你的模塊代碼的基本輪廓，構建配置等。 – datenwolf

作爲@datenwolf方式，鏈接需要特殊的注意事項。哪些對我來說是個謎，但是使用ldd會有所幫助。所以基本上我所做的就是在最終和中間共享對象中使用ldd。儘管有命令行參數，但我的庫並沒有與libGL及其依賴關係鏈接，直到我還在中間步驟中包含'-lGL -lGLU -lX11'（生成'liblayouter.so'）。

來源

2012-10-23 13:02:48 dsign

其實這並不令人意外，因爲它是liblayouter.so，顯然要求libGL.so的功能。因此，它必須包含動態鏈接條目。共享對象liblayouter_mod.so反過來會動態鏈接到liblayouter.so。現在，如果將-lGL添加到_mod.so，則只有_mod.so實際上可以看到libGL.so，而liblayouter.so卻是乾的。另外請記住，_mod.so在它的動態鏈接器路徑中確實需要liblayouter.so。 – datenwolf

@datenwolf感謝您的幫助。我想結束這個問題。你可以把你最後的評論作爲你的答案，以便我可以接受它嗎？ – dsign

我編輯了我的答案 – datenwolf

正確鏈接Ubuntu中的GLX庫

回答

相關問題