我的文件链接到libGL.so.1

my files linking to libGL.so.1

本文关键字：so libGL 文件 链接 我的      更新时间：2023-10-16

好的，所以我不确定这是否发生相应的，但当我使用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。在相同的目录下/usr/lib/x86....../libGL.so

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

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

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

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

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

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

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

然而，在不同供应商的gpu系统上，事情变得棘手;在Linux上没有正式指定的ICD机制。但是存在(相当多的)libGL。因此，调度程序/代理会查看进程启动时所在的图形环境，并加载相应的供应商libGL。从这里开始。通常的实现是启动一个小的辅助程序，它使用GLX传输来创建一个间接的OpenGL上下文，读取OpenGL版本字符串并返回实际libGL的路径。所以用了be。这是有效的，因为X服务器中的GLX模块与OpenGL实现的关系是硬编码的，GLX可以在不需要libGL的情况下进行对话。so(参见Xcb中的GLX模块)。

一般来说，如果你不知道你在做什么，你不应该乱动系统中的共享对象。只要把你的程序链接到-lGL，链接器就会从那里开始。

相关文章：