【问题标题】:/usr/lib appears not to be a default link location/usr/lib 似乎不是默认链接位置
【发布时间】:2013-01-22 08:31:39
【问题描述】:

编辑:
经过一番挖掘后,我发现我在/usr/lib/i386-linux-gnu/libGL.so 有一个 libGL.so,如果我将其移开,则链接将再次正常工作。在查看错误行一段时间后,我认为消息中 libGL.so 的完整路径是可疑的,因为它会一直在查看多个位置来找到它,并且通常它只显示库的名称而不是一个特定的完整路径小路。所以现在的问题是;为什么找到其他版本会导致搜索停止并显示令人困惑的错误消息? (我是 i386ness 在某种程度上使它不兼容)。

起源:
出于某种原因,我无法将 libGL.so 链接到我的应用程序中。问题似乎是 ld (或在这种情况下为 gold )在尝试找到它时没有在 /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 x86
g++ 4.7
GNU 黄金链接器
CPU AMD Phenom 2 x6
uname -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

【问题讨论】:

  • 显示你链接的命令行?如果你添加 -v 到它的消息呢?
  • 什么是 CPU 架构? x86 还是 x86-64?您可以通过运行uname -m 来检查。
  • 更新了详细的主要描述
  • 您的日志输出清楚地表明环境库LIBRARY_PATH 不包括/usr/lib。我不确定是什么设置了它,但这应该会指出你应该去哪里看。
  • 嗯,:/usr/lib/ 就在LIBRARY_PATH 行的末尾呢?

标签: c++ linux linker


【解决方案1】:

经过大量挖掘后,我发现我是一个悬空符号链接的受害者(这基本上是一个没有链接到有效内容的符号链接)。所以发生的事情是链接器在/usr/lib/i386-linux-gnu/libGL.so 找到了一个libGL.so 并决定它的搜索已经结束,但是当它试图获取文件时,符号链接的末尾没有任何内容,这导致了我的错误消息看到。一旦我删除了悬空符号链接,搜索就找不到libGL.so,直到它到达/usr/lib/libGL.so 的正确版本,此时一切正常。

【讨论】:

    【解决方案2】:

    似乎您的库路径由于某种原因未设置。您的配置是否有设置 --libexecdir=/usr/lib 的选项。我有类似的问题,缺少 --libexecdir 的这个选项。

    您可以通过在 makefile 中传递 LDFLAGS 来修复它。如何在 makefile 中使用 LDFLAGS 已取消here。 您使用 -L/usr/lib 的选项也很完美。

    【讨论】:

    • 嗨,我知道 -L 将是一种解决方法。我真的很想知道为什么默认情况下不搜索 /usr/lib,我使用 makefile 生成工具并在所有 makefile 中添加多余的 -L 不是我想要的解决方案。
    • @radman 很抱歉误解了您的问题。看到您的编辑后,我自己有点困惑。哈哈!!!
    【解决方案3】:

    我刚刚遇到了类似的问题,当gcc 需要一个明确的-L/usr/lib 库搜索选项时;即使它应该已经在默认库搜索路径中。奇怪的是,所有库都可用,ldconfig 也正确定位它们。

    感谢@radman 的发现,我记得创建了一个指向 .a 静态库的符号链接,该库最初安装在 /usr/lib 中,但我在寻找其他一些配置/构建问题时将它的符号链接添加到 /usr/lib/i386-linux-gnu 中。

    删除该符号链接(有效,非悬空)清除了库搜索问题,因此 gcc 可以正确找到没有显式 -L/usr/lib 的库

    【讨论】:

      猜你喜欢
      • 2011-11-18
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 2017-04-10
      • 2019-11-05
      • 2023-03-19
      • 1970-01-01
      相关资源
      最近更新 更多