c++ - 我的文件链接到 libGL.so.1

Question

好的，所以我不确定这是否相应地发生了，但是当我使用 g++ 时，我的文件似乎链接到 libGL.so.1

这是我运行 ldd 时的部分输出

ldd a.out 
linux-vdso.so.1 =>  (0x00007fff151fe000)
libGLEW.so.1.10 => /usr/lib/x86_64-linux-gnu/libGLEW.so.1.10     (0x00007f86d4242000)
libglfw.so.3 => /usr/lib/libglfw.so.3 (0x00007f86d4028000)
libGL.so.1 => /usr/lib/x86_64-linux-gnu/libGL.so.1 (0x00007f86d3cf8000)

现在，当我搜索我的 libGL.so 文件时，它会在同一目录/usr/lib/x86....../libGL.so 中找到它

现在我的问题是为什么它链接到 ...so.1 而不是 libGL.so

我似乎也安装了 mesa-dev 库，但我想确保我的 GL 链接是针对图形驱动程序而不是 mesa 库，我需要卸载 mesa 驱动程序并在此处重新链接库吗？

我需要删除 libgl1-mesa* 文件吗？当我安装显卡驱动程序时需要它们吗？

Answer 1

ldd 显示程序有效 链接到什么。没有在编译时给出哪个文件或库。共享对象有一个叫做 soname 的东西，它是一种版本控制系统。当您的程序链接到 libGL.so 时，链接器从所使用的特定样本中提取出 soname 实际上是 libGL.so.1 并将该名称放入你的程序二进制文件。

在运行时，动态链接器 ld.so 在整个目录范围内查找与此 soname 匹配的共享对象。可以配置目录列表，参见 man ld.so 和 man ldconfig。

现在 libGL.so 是一个棘手的野兽。它通常作为图形驱动程序的一部分提供。对于 Linux，周围有几个驱动程序包:

• Mesa，开源 OpenGL 实现和驱动程序
• NVidia 的专有 blob
• AMD 的专有 blob

然而，在使用来自不同供应商的 GPU 的系统上，事情变得更加棘手； Linux 上没有正式指定的 ICD 机制。但是存在(相当多的)libGL.so 调度程序/代理，它们查看进程已启动的图形环境，并从那里加载适当的供应商 libGL.so。通常的实现是启动一个小的帮助程序，它使用 GLX 传输创建一个间接的 OpenGL 上下文，读取 OpenGL 版本字符串并返回到实际 libGL.so 的路径，以便使用。这是有效的，因为 X 服务器中的 GLX 模块与 OpenGL 实现的关系是硬编码的，并且可以在不需要 libGL.so 的情况下讨论 GLX(例如参见 Xcb 中的 GLX 模块)。

一般来说，如果您不知道自己在做什么，则不应弄乱系统中的共享对象。只需将您的程序与 -lGL 链接起来，链接器就会从那里获取它。