str*_*cat 5 linker shared-library
在我的 Linux Mint 17.3 系统上，我安装了软件包libglfw2和libglfw-dev. 由于 GLFW v3 在存储库中不可用，我选择使用此处的说明手动编译它。
我在网上找到的几乎所有说明都说明要链接到 GLFW v2，我应该使用 .-lglfw而对于 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 中的所有路径都是正确的。但是，在卸载我使用apt-get并运行安装的 GLFW v2 打包后ldconfig，-lglfw工作没有问题。似乎在 CMake 文件的某个地方（我猜），有一个导致名称冲突的错误。
我的问题是：如果我有两个提供相同名称的共享库的源，并且如果我同时需要它们，我该怎么做（缺少构建配置）来解决这个问题？我可以so可靠地手动更改文件名吗？
共享库被称为例如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 并肩而立的想法感到兴奋）。
你最好的选择是依靠你的发行版来为你设置这个混乱。