我正在构建一个RPM，它基本上只是打包一组供应商提供的.so二进制文件，以便它们可用于我们的内部应用程序，也可以通过RPM安装。
其中一个库附带了多个版本 - libexample_base.so和libexample_debug.so（以及其他版本）。我目前正在尝试打包这些以便它们都包含在RPM中（以便开发人员可以根据需要在它们之间切换），但是通过在％install期间创建符号链接来选择libexample_base.so作为默认版本，然后将其打包为RPM中的文件。
%install
[... Copy the files from the tarball to the buildroot ...]
pushd %{buildroot}%{_libdir}
ln -sf libexample_base.so libexample.so
popd
这很有效...除了一个问题。它使用自动依赖关系生成，虽然它提供了所有具有实际文件的共享对象，但它不提供libexample.so，尽管符号链接在％文件中并且已安装正常。不幸的是，供应商库不提供SONAME条目，因为它们是二进制blob，我不能轻易添加它们，因此RPM取决于实际的文件名。所有下游RPM都需要libexample.so，并且由于此RPM未将其列为需求，因此它们由于缺少依赖性而拒绝安装，即使实际上有效（ldconfig可以找到没有问题的libexample.so）。 / p>
关于如何提示rpmbuild将符号链接解析为提供的任何想法？
答案 0 :(得分：1)
经过一些进一步的研究，我已经确定我想要做的事情是不可能的，以及为什么。核心问题归结为rpmbuild的行为，该行为是为了使用SONAME条目处理正确生成的共享对象而构建的。它明确地没有列出符号链接到以.so提供的共享对象，因为正常行为，那些指向版本化共享对象（.so。＃。＃），并且您的应用程序应该依赖于那些版本化对象 - symlink旨在包含在devel包中，只是为了让链接器找到最新的链接。
我遇到第二个案例，当事情没有正确完成时用作备份 - 对于RPM和GCC，当没有SONAME时，它使用文件名。当我运行GCC时，文件名是libexample.so（真实的符号链接），它没有SONAME，所以它只是将自己配置为链接libexample.so; rpmbuild看到了这一点，并将其设置为应用程序RPM的要求。但是，由于rpmbuild明确地从库rpm中排除了该名称，因为它看起来像是一个开发链接，因此无法协调这两个rpms。
解决方案？现在，我正在使用我的解决方法，只是制作文件的副本 - 当有一个具有该名称的物理文件时，它可以工作。正确的方法是修复共享对象，尽管我需要去上游供应商完成这项工作。