2013-05-17 390 views
0

我安裝了這兩個庫:glut和curl。Linux - 找到g ++ lib的路徑

sudo apt-get install libcurl4-gnutls-dev 
sudo apt-get install freeglut3-dev 

當我必須編譯程序使用:

g++ -o executable file11.cpp file2.cpp -lglut -lcurl 

和它的作品!

我怎麼知道鏈接器在哪裏搜索「-lglut」或「-lcurl」?

「-lsomething」對應一條路徑,我怎樣才能知道?

回答

1

連接器將看在由-L選項指定的目錄和標準系統目錄中,這通常是/lib/usr/lib。儘管您沒有使用任何-L選項,但GCC通常會將一些選項傳遞給鏈接程序,以便它可以找到GCC自己的庫(例如C++標準庫),除非使用-nostdlib。 GCC還會爲LIBRARY_PATH環境變量的內容添加-L選項。

要查看GCC傳遞給連接器的選項,你可以用-v編譯(用於詳細),看看哪些庫鏈接器使用,你可以通過-Wl,--trace到GCC,這會導致它通過--trace給連接器,這使得它輸出類似:

/usr/bin/ld: mode elf_x86_64 
/usr/lib/gcc/x86_64-redhat-linux/4.7.2/../../../../lib64/crt1.o 
/usr/lib/gcc/x86_64-redhat-linux/4.7.2/../../../../lib64/crti.o 
/usr/lib/gcc/x86_64-redhat-linux/4.7.2/crtbegin.o 
/tmp/ccJHrbSx.o 
-lglut (/usr/lib/gcc/x86_64-redhat-linux/4.7.2/../../../../lib64/libglut.so) 
-lcurl (/usr/lib/gcc/x86_64-redhat-linux/4.7.2/../../../../lib64/libcurl.so) 
-lgcc_s (/usr/lib/gcc/x86_64-redhat-linux/4.7.2/libgcc_s.so) 
/lib64/libc.so.6 
(/usr/lib64/libc_nonshared.a)elf-init.oS 
/lib64/ld-linux-x86-64.so.2 
-lgcc_s (/usr/lib/gcc/x86_64-redhat-linux/4.7.2/libgcc_s.so) 
/usr/lib/gcc/x86_64-redhat-linux/4.7.2/crtend.o 
/usr/lib/gcc/x86_64-redhat-linux/4.7.2/../../../../lib64/crtn.o 

這表明發現了我的系統上-lglutlcurl庫,該庫。該庫是在路徑中找到,因爲我的系統上GCC傳遞-L/usr/lib/gcc/x86_64-redhat-linux/4.7.2/../../../../lib64使用readlink

$ readlink -f /usr/lib/gcc/x86_64-redhat-linux/4.7.2/../../../../lib64/ 
/usr/lib64/ 
2

它檢查/lib,/usr/lib和任何路徑傳遞給-L

0

嘗試

ldd /path/to/your/executable 
+0

鏈接(通過與-v編譯所示)

您可以規範化的路徑,告訴你在運行時鏈接找到所需的庫,它們不一定和鏈接時發現它們的位置相同 –

+0

@JonathanWakely查看帖子,似乎(1)沒有標誌被傳遞給指示庫的位置的鏈接器,以及(2)編譯的程序正在同一系統上執行,而不指定'LD_LIBRARY_PATH'。在這種情況下,'ldd'幾乎會產生與* compilation *相同的一組庫。 – devnull

+0

不一定。鏈接時'$ LD_RUN_PATH'的內容和運行時'ld.so.conf'的內容都會影響到它。所以雖然'ldd'可能有用,但並不總是顯示與在鏈接時找到的庫相同的內容。正如我所說,這不一定是一樣的。 –