在我的 Linux Mint 17.3 系统上，我安装了软件包libglfw2和libglfw-dev.由于 GLFW v3 在存储库中不可用，我选择使用指令手动编译它这里。
我在网上找到的几乎所有说明都表明要链接到 GLFW v2，我应该使用-lglfwwhile 对于 GLFW v3，它应该是-lglfw3.然而，这样做却-lglfw3出现了错误：
/usr/bin/ld: cannot find -lglfw3
使用时-lglfw出现很多错误，例如：
1.cpp:(.text+0x49): undefined reference to <function_name>
可以肯定的是，C_INCLUDE_PATH 和 LD_LIBRARY_PATH 中的所有路径都是正确的。然而，在卸载 GLFW v2 打包后，我已经安装apt-get并运行了ldconfig，-lglfw工作没有问题。似乎在 CMake 文件中的某个地方（我猜）存在导致名称冲突的错误。
我的问题是：如果我有两个提供相同名称的共享库的源，并且如果我需要它们，我可以做什么（除了深入构建配置之外）来解决该问题？我可以可靠地手动更改文件名so吗？
答案1
共享库被称为例如libfoo.so-x.y.z，其想法是z对于较小的（完全向后兼容）更改而增加，y对于保持向后兼容性的API添加而增加，而x对于主要API更改（不兼容）保留更改。可执行程序（检查例如ldd(1)可执行文件的输出）通过主编号 ( ) 告诉您程序请求哪个库，libfoo.so.x以及使用哪个库来满足该依赖关系 ( libfo.so.x.y.z)。 “链接libfoo.so.x”在构建时固定，y.z在启动时固定。因此，您可以更改y和/或z让程序仍然工作，并且同时安装例如libfoo.so.3和安装，某些程序使用其中一个或其他程序而不会发生冲突。libfoo.so.4
如果您查看库的目录，您将看到一系列符号链接，例如libfoo.so -> libfoo.so.x -> libfoo.so.x.y.z；当与-lfoo链接器链接时将遵循此并添加libfoo.so.x为可执行文件的依赖项，并用于libfoo.so.x.y.z解析符号。
该机制经过专门设计，可以在编译时始终获得最新版本libfoo，同时为遗留应用程序提供旧版本。因此，您经常会看到例如libbar.soand libbar3.so（以及它们的符号链接场）能够针对版本 2 （-lbar，如果未编号的旧版本是 2 ）或 3 （-lbar3）进行构建。
建造机械应该能够解决这个问题，但这相当棘手（并不是每个人都对他们最新、最闪亮的版本 3 将与陈旧的版本 2 并肩而立的想法感到兴奋）。
你最好的选择是依靠你的发行版来为你设置这个混乱。