連接器將看在由-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
這表明發現了我的系統上-lglut
和lcurl
庫,該庫。該庫是在路徑中找到,因爲我的系統上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/
鏈接(通過與
-v
編譯所示)您可以規範化的路徑,告訴你在運行時鏈接找到所需的庫,它們不一定和鏈接時發現它們的位置相同 –
@JonathanWakely查看帖子,似乎(1)沒有標誌被傳遞給指示庫的位置的鏈接器,以及(2)編譯的程序正在同一系統上執行,而不指定'LD_LIBRARY_PATH'。在這種情況下,'ldd'幾乎會產生與* compilation *相同的一組庫。 – devnull
不一定。鏈接時'$ LD_RUN_PATH'的內容和運行時'ld.so.conf'的內容都會影響到它。所以雖然'ldd'可能有用,但並不總是顯示與在鏈接時找到的庫相同的內容。正如我所說,這不一定是一樣的。 –