【问题标题】:How to link shared library against alternate version of libGL?如何将共享库链接到 libGL 的替代版本?
【发布时间】:2013-01-13 15:52:34
【问题描述】:

我在我的主目录下构建了一个本地版本的 OpenGL。我想将另一个共享库链接到它,但由于某种原因,链接器仍然将它链接到 /usr/lib 下的共享库,正如 ldd 报告的那样:

$ cc -o lib/libtfont.so -shared -Wl,-soname,/home/wknight/proj/wkl/tfont.lib/lib/libtfont.so tfont.o -L/home/wknight/proj/wkl/img .lib/lib -limg -L/home/wknight/swtools/opengl/lib -lGL -lGLU $ ldd lib/libtfont.so linux-gate.so.1 => (0xb7710000) /home/wknight/proj/wkl/img.lib/lib/libimg.so (0xb76fc000) libGL.so.1 => /usr/lib/libGL.so.1 (0xb7689000) libGLU.so.1 => /usr/lib/libGLU.so.1 (0xb7618000) libc.so.6 => /lib/i686/cmov/libc.so.6 (0xb74d1000) libX11.so.6 => /usr/lib/libX11.so.6 (0xb73b4000) libXext.so.6 => /usr/lib/libXext.so.6 (0xb73a5000) libXxf86vm.so.1 => /usr/lib/libXxf86vm.so.1 (0xb73a0000) libXdamage.so.1 => /usr/lib/libXdamage.so.1 (0xb739c000) libXfixes.so.3 => /usr/lib/libXfixes.so.3 (0xb7397000) libdrm.so.2 => /usr/lib/libdrm.so.2 (0xb738d000) libm.so.6 => /lib/i686/cmov/libm.so.6 (0xb7367000) libpthread.so.0 => /lib/i686/cmov/libpthread.so.0 (0xb734e000) libdl.so.2 => /lib/i686/cmov/libdl.so.2 (0xb7349000) libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0xb7254000) libgcc_s.so.1 => /lib/libgcc_s.so.1 (0xb7236000) /lib/ld-linux.so.2 (0xb7711000) libxcb.so.1 => /usr/lib/libxcb.so.1 (0xb721d000) librt.so.1 => /lib/i686/cmov/librt.so.1 (0xb7214000) libXau.so.6 => /usr/lib/libXau.so.6 (0xb7211000) libXdmcp.so.6 => /usr/lib/libXdmcp.so.6 (0xb720b000) $ ls -l /home/wknight/swtools/opengl/lib/libGL* lrwxrwxrwx 1 wknight wknight 10 Jan 25 16:57 /home/wknight/swtools/opengl/lib/libGL.so -> libGL.so.1 lrwxrwxrwx 1 wknight wknight 12 Jan 25 16:57 /home/wknight/swtools/opengl/lib/libGL.so.1 -> libGL.so.1.2 -rwxr-xr-x 1 wknight wknight 1836469 Jan 25 16:57 /home/wknight/swtools/opengl/lib/libGL.so.1.2 lrwxrwxrwx 1 wknight wknight 11 Jan 25 16:57 /home/wknight/swtools/opengl/lib/libGLU.so -> libGLU.so.1 lrwxrwxrwx 1 wknight wknight 20 Jan 25 16:57 /home/wknight/swtools/opengl/lib/libGLU.so.1 -> libGLU.so.1.3.070900 -rwxr-xr-x 1 wknight wknight 1634905 Jan 25 16:57 /home/wknight/swtools/opengl/lib/libGLU.so.1.3.070900 lrwxrwxrwx 1 wknight wknight 11 Jan 25 16:57 /home/wknight/swtools/opengl/lib/libGLw.so -> libGLw.so.1 lrwxrwxrwx 1 wknight wknight 15 Jan 25 16:57 /home/wknight/swtools/opengl/lib/libGLw.so.1 -> libGLw.so.1.0.0 -rwxr-xr-x 1 wknight wknight 37068 Jan 25 16:57 /home/wknight/swtools/opengl/lib/libGLw.so.1.0.0 $

即使我重命名本地版本的 libGL.so 并链接到新名称,也会发生这种情况。所以在幕后发生了一些我不明白的事情。链接器是在寻找 ld.so.cache 还是什么?如何覆盖它?

【问题讨论】:

    标签: opengl linker shared-libraries


    【解决方案1】:

    我找到了答案 - 我只需要将 LD_LIBRARY_PATH 设置为我的本地版本的 libGL.so:

    $ 出口 LD_LIBRARY_PATH=$HOME/swtools/opengl/lib $ ldd lib/libtfont.so linux-gate.so.1 => (0xb778c000) /home/wknight/proj/wkl/img.lib/lib/libimg.so (0xb7778000) libGL.so.1 => /home/wknight/swtools/opengl/lib/libGL.so.1 (0xb771f000) libGLU.so.1 => /home/wknight/swtools/opengl/lib/libGLU.so.1 (0xb76ae000) libc.so.6 => /lib/i686/cmov/libc.so.6 (0xb7559000) libX11.so.6 => /usr/lib/libX11.so.6 (0xb743c000) libXext.so.6 => /usr/lib/libXext.so.6 (0xb742d000) libXdamage.so.1 => /usr/lib/libXdamage.so.1 (0xb742a000) libXfixes.so.3 => /usr/lib/libXfixes.so.3 (0xb7424000) libXxf86vm.so.1 => /usr/lib/libXxf86vm.so.1 (0xb741f000) libdrm.so.2 => /usr/lib/libdrm.so.2 (0xb7415000) libpthread.so.0 => /lib/i686/cmov/libpthread.so.0 (0xb73fc000) libdl.so.2 => /lib/i686/cmov/libdl.so.2 (0xb73f8000) libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0xb7302000) libm.so.6 => /lib/i686/cmov/libm.so.6 (0xb72dc000) libgcc_s.so.1 => /lib/libgcc_s.so.1 (0xb72be000) /lib/ld-linux.so.2 (0xb778d000) libxcb.so.1 => /usr/lib/libxcb.so.1 (0xb72a5000) librt.so.1 => /lib/i686/cmov/librt.so.1 (0xb729c000) libXau.so.6 => /usr/lib/libXau.so.6 (0xb7299000) libXdmcp.so.6 => /usr/lib/libXdmcp.so.6 (0xb7293000) $

    当我认为 ldd 必须使用运行时环境来报告共享库依赖项时,这对我来说很有意义,而不仅仅是共享库本身中存在的内容。在使用链接到共享库的某些可执行文件之前,我会设置 LD_LIBRARY_PATH,但直到现在我才想到我还必须设置它以检查共享库本身。

    【讨论】:

      【解决方案2】:

      我在我的主目录下构建了一个本地版本的 OpenGL

      为什么?你这样做的目的是什么? OpenGL 与其说是一个库,不如说是一个规范。您构建的很可能是 MesaGL。 MesaGL 确实仅通过特定的驱动程序子集提供硬件加速 OpenGL,这些驱动程序也必须与您的 MesaGL 版本相匹配。没有它们,MesaGL 将陷入缓慢的软件光栅化程序回退。

      作为一般规则,您始终将程序动态链接到系统的 libGL.so。如果没有 libGL.so,那么只有当您能够处理非常慢的软件光栅化器时,才会提供回退实现。否则我最好只告诉用户他的系统缺点,或者必须安装更好的 GPU,或者修复驱动程序安装。


      无论如何,如果您想更改搜索库的路径,您应该查看rpath 链接器标志。

      【讨论】:

      • 我链接 MesaGL 版本的目的是为了更好地理解驱动程序的内部结构。我还要看看 rpath 标志是否有效,谢谢。
      • @WilliamKnight:通过链接 MesaGL,您将无需了解某些驱动程序内部。您将学到的只是 MesaGL 的内部结构——如果您的系统支持并使用它,则还有 DRI/DRM 基础设施。但是您可以通过阅读他们的源代码并使用 cscope 或 egypt 等工具分析代码流来更好地了解这些内容。
      • 好的,谢谢。我还有很多东西要学——在链接到 MesaGL 库的本地版本后,我现在得到这样的东西:“X 服务器不支持 GLXFBConfigs,glGenTextures() 失败”
      • @WilliamKnight:嗯,这并不意外。很可能您的 Mesa 编译试图与 X11 服务器另一端的驱动程序通信……它不理解它,因为它是一个不匹配的版本。正如我已经告诉过您的,尝试与自定义 libGL.so 链接没有任何好处。如果您想在系统运行时查看引擎盖,只需安装调试符号。在 debian 上,例如 libgl1-mesa-dri-dbg 和 libgl1-mesa-glx-dbg – 请注意,如果您使用的是 NVidia 或 ATI/AMD 专有驱动程序,则无法“查看”它们。他们是闭源的,不会与 Mesa 合作
      猜你喜欢
      • 1970-01-01
      • 1970-01-01
      • 2010-10-24
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      相关资源
      最近更新 更多