好吧所以我不确定这是否相应发生，但是当我使用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 *文件吗？我安装显卡驱动程序时需要它们吗？
答案 0 :(得分：2)
ldd向您展示有效链接到的程序。不是在编译时给出了哪个文件或库。共享对象有一个叫做 soname 的东西，它是一种版本控制系统。当您的程序与libGL.so链接从所使用的特定样本中提取的链接器时，声纳实际上是libGL.so.1并将该名称放入您的程序二进制文件中。
在运行时，动态链接器ld.so在一系列目录中查找与此soname匹配的共享对象。可以配置目录列表，请参阅man ld.so和man ldconfig。
现在libGL.so是一个棘手的野兽。它通常作为图形驱动程序的一部分提供。对于Linux，有几个驱动程序包：
然而，在使用来自不同供应商的GPU的系统上，事情会变得棘手; Linux上没有正式指定的ICD机制。但是存在（很多）libGL.so调度程序/代理，它们查看已启动进程的图形环境并从那里加载适当的供应商libGL.so。通常的实现是启动一个小帮助程序，它使用GLX传输创建一个间接的OpenGL上下文，读取OpenGL版本字符串并返回实际libGL的路径。这是有效的，因为X服务器中的GLX模块与OpenGL实现的关系是硬编码的，并且可以在不需要libGL.so的情况下讨论GLX（参见例如Xcb中的GLX模块）。
一般情况下，如果您不知道自己在做什么，就不应该弄乱系统中的共享对象。只需将您的程序与-lGL链接，链接器就可以从那里获取它。