连接器将看在由-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'可能有用,但并不总是显示与在链接时找到的库相同的内容。正如我所说,这不一定是一样的。 –