我找到了一个库，libjson试图将其构建为共享库并在项目中使用。建筑很简单；修复Makefile错误后，
# SHARED=1 make install
将编译并安装.soin /usr/lib。问题是我的系统（Arch Linux）已经有一个名为的库libjson，Makefile为我覆盖了它！Arch的库已作为依赖项安装，因此无法替换。如果其他发行版有一个名为的库，则大概也会遇到类似的问题libjson。
我该怎么办？我可以重命名库（libjson-mine或其他东西），但是动态链接离魔术只有几步之遥，所以我不知道这是否会破坏某些东西。如何重命名库？
另一个选择是将库的源代码放入我当前项目的源树中，然后让构建器创建一个静态库。（显然，这会使我的代码存储库有点混乱，因此是不合需要的。）如果我走了这条路线，则需要使链接程序更喜欢我的链接器，libjson.a而不是搜索/usr/lib“合适的”（读：错误的）库。如何使链接器首选我的版本？
或者，还有我不知道的第三种选择吗？
背景概念
共享库有两个使用点：
ld）如果您在gcc中使用进行编译-llibjson，则基本名称将存储在可执行文件中
在执行时，将在标准路径中搜索该基名。
在链接时，链接器必须能够在其搜索路径上找到您的库。前置搜索路径并不容易：
您也许可以摆脱/usr/local/lib针对用户编译库的需求，并且应该早于此/usr/lib。
但是这样做会破坏使用其他方法的任何东西libjson，因此您可能不希望这样做。
如果在gcc中用-l:/full/path/to/libjson.so完整路径进行编译，则会将其存储在可执行文件中。
执行时，不需要路径搜索，因为我们已经有了完整的路径。
您可以使用以下命令检查存储在可执行文件中的文件：
readelf -d a.out | grep 'Shared library'
可能的解决方案
我看不到任何不需要编辑Makefile项目的好的解决方案，因此详细信息是特定于项目的。但总的来说，您可以：
编辑该库的Makefile或类似文件，然后将基本名称重命名为libjson_mine.so。
使用以下命令编译需要该库的程序-ljson_mine。这将起作用，因为我们知道该路径/usr/lib在.so搜索路径中。
这是最好的选择，迟早要这样做，否则将导致无休止的混乱……发送请求请求！
在相同的拉取请求中，还将默认安装目录更改/usr/local/lib为/usr/lib。这是理智的用户编译库在默认情况下必须存在的位置，正是为了避免覆盖分发的库。
如果所有者不想重命名该库，请在Makefile中找到一个选项来更改生成的库的基本名称。
如果该选项不存在，请拉取请求。如果所有者不想接受，则分叉项目；-)
然后，您和您的发行版可以在编译时使用该选项。
在Makefile中找到一个选项，该选项会更改安装了库+标头的目录，然后使用完全自定义的（~/usr/lib，~usr/include），然后将其添加到动态加载程序搜索路径中。如何指定库路径的首选项？+包括搜索路径。有关GNU方法，请参见make的DESTDIR和PREFIX。
然后在编译/执行时，更改包含/动态加载程序的搜索路径。
并不理想，但可以一次性使用。
本文收集自互联网，转载请注明来源。
如有侵权，请联系[email protected] 删除。
我来说两句