编辑：经过进一步的挖掘，我发现我在/usr/lib/i386-linux-gnu/libGL.so处有一个libGL.so，如果我将其移开，则链接将再次正常工作。在看了错误行一会儿之后，我认为消息中libGL.so的完整路径是可疑的，因为它会一直在多个位置查找它，并且通常只显示库名而不是一个特定的完整目录。路径。现在的问题是；为什么找到其他版本导致搜索停止并显示令人困惑的错误消息？ （我是i386ness，使其在某种程度上不兼容）。
原件：由于某种原因，我无法将libGL.so链接到我的应用程序中。问题似乎是ld（在这种情况下为gold）在/ usr / lib中找不到（我能找到的所有内容都是默认位置之一），而在usr / lib中寻找的却不是怪异的位置，例如
/ usr / bin / ld：错误：无法打开/usr/lib/gcc/i686-linux-gnu/4.7/../../../i386-linux-gnu/libGL.so：否这样的文件或目录
现在/usr/lib/libGL.so确实存在，如果在makefile中执行显式的-L / usr / lib，则所有链接都正确。
我想知道有人知道这里发生了什么吗？
信息：Ubuntu Linux 12.10 x86g ++ 4.7GNU黄金链接器CPU AMD Phenom 2 x6uname -m out：i686
编辑：具有-v参数的链接的输出：
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc/i686-linux-gnu/4.7/lto-wrapper
Target: i686-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro 4.7.2-2ubuntu1' --with-bugurl=file:///usr/share/doc/gcc-4.7/README.Bugs --enable-languages=c,c++,go,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.7 --enable-shared --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.7 --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object --enable-plugin --enable-objc-gc --enable-targets=all --disable-werror --with-arch-32=i686 --with-tune=generic --enable-checking=release --build=i686-linux-gnu --host=i686-linux-gnu --target=i686-linux-gnu
Thread model: posix
gcc version 4.7.2 (Ubuntu/Linaro 4.7.2-2ubuntu1)
COMPILER_PATH=/usr/lib/gcc/i686-linux-gnu/4.7/:/usr/lib/gcc/i686-linux-gnu/4.7/:/usr/lib/gcc/i686-linux-gnu/:/usr/lib/gcc/i686-linux-gnu/4.7/:/usr/lib/gcc/i686-linux-gnu/
LIBRARY_PATH=/usr/lib/gcc/i686-linux-gnu/4.7/:/usr/lib/gcc/i686-linux-gnu/4.7/../../../i386-linux-gnu/:/usr/lib/gcc/i686-linux-gnu/4.7/../../../../lib/:/lib/i386-linux-gnu/:/lib/../lib/:/usr/lib/i386-linux-gnu/:/usr/lib/../lib/:/usr/lib/gcc/i686-linux-gnu/4.7/../../../:/lib/:/usr/lib/
COLLECT_GCC_OPTIONS='-o' 'application' '-v' '-L/home/user/src/tutorials/application/builds/./vendor/ogre3d/./lib' '-shared-libgcc' '-mtune=generic' '-march=i686'
/usr/lib/gcc/i686-linux-gnu/4.7/collect2 --sysroot=/ --build-id --no-add-needed --as-needed --eh-frame-hdr -m elf_i386 --hash-style=gnu -dynamic-linker /lib/ld-linux.so.2 -z relro -o application /usr/lib/gcc/i686-linux-gnu/4.7/../../../i386-linux-gnu/crt1.o /usr/lib/gcc/i686-linux-gnu/4.7/../../../i386-linux-gnu/crti.o /usr/lib/gcc/i686-linux-gnu/4.7/crtbegin.o -L/home/user/src/tutorials/application/builds/./vendor/ogre3d/./lib -L/usr/lib/gcc/i686-linux-gnu/4.7 -L/usr/lib/gcc/i686-linux-gnu/4.7/../../../i386-linux-gnu -L/usr/lib/gcc/i686-linux-gnu/4.7/../../../../lib -L/lib/i386-linux-gnu -L/lib/../lib -L/usr/lib/i386-linux-gnu -L/usr/lib/../lib -L/usr/lib/gcc/i686-linux-gnu/4.7/../../.. /home/user/src/tutorials/application/builds/./src/most_basic_main.o /home/user/src/tutorials/application/builds/./src/QOgreWidget.o /home/user/src/tutorials/application/builds/./src/QtOgreApplication.o /home/user/src/tutorials/application/builds/./src/qt_gen/QtOgreApplication.moc.o /home/user/src/tutorials/application/builds/./src/qt_gen/QOgreWidget.moc.o -lpthread -lQtCore -lQtNetwork -lQtGui -lQtOpenGL -lRenderSystem_GLStatic -lOgreMainStatic -ldl -lfreetype -lXrandr -lGL -lGLU -lxcb -lX11 -lXext -lXpm -lXaw7 -lXt -lzzip -lfreeimage -lstdc++ -lm -lgcc_s -lgcc -lc -lgcc_s -lgcc /usr/lib/gcc/i686-linux-gnu/4.7/crtend.o /usr/lib/gcc/i686-linux-gnu/4.7/../../../i386-linux-gnu/crtn.o
/usr/bin/ld: error: cannot open /usr/lib/gcc/i686-linux-gnu/4.7/../../../i386-linux-gnu/libGL.so: No such file or directory
经过一番挖掘，结果证明我是一个悬空的符号链接的受害者（该符号链接基本上是一个不链接到有效对象的符号链接）。因此发生的是，链接器在libGL.so处找到了一个/usr/lib/i386-linux-gnu/libGL.so并确定其搜索结束了，但是，当它尝试获取该文件时，符号链接的末尾没有任何内容，从而导致出现错误消息：看到。一旦我删除了悬空的符号链接，搜索就没有找到libGL.so，直到找到/usr/lib/libGL.so的正确版本为止，此时一切都按预期进行。
似乎由于某些原因，您的库路径未设置。您的配置是否可以选择设置--libexecdir = / usr / lib。在--libexecdir的此选项丢失的情况下，我遇到了类似的问题。
您可以通过在makefile中传递LDFLAGS来修复它。关于如何在makefile中使用LDFLAGS的问题已被淘汰here。使用-L / usr / lib的选项也很完美。
[当C0]需要显式的gcc库搜索选项时，我遇到了类似的问题；即使它应该已经在默认库搜索路径中。奇怪的是，所有库都可用，-L/usr/lib也可以正确找到它们。
由于@radman的发现，我记得创建了一个指向.a静态库的符号链接，该库最初安装在ldconfig中，但是我在追寻其他一些configure / build问题时，将它的符号链接添加到了/usr/lib中。 >
删除该符号链接（有效，不悬挂）已解决了库搜索问题，因此gcc可以在没有显式/usr/lib/i386-linux-gnu的情况下正确找到该库