我有一个较旧的系统（Fedora Core 6，它是一个孤立的系统，用于为旧设备构build）。 我试图build立一个匹配的虚拟机，我注意到我无法解释的差异。
两个系统都包含glibc-2.5-3包，其中包含文件/lib/libc-2.5.so。
rpm -qi glibc输出在两个系统上完全匹配。
在这两个系统上， rpm -Vv表示一切正常（ ........ /lib/libc-2.5.so ）。
两个系统上文件的md5sum不匹配。 （
当我在两个系统上执行objdump -x文件时，我得到了不同的起始地址值，确认实际上这两个SO文件是不同的。
那么，为什么rpm -V告诉我，md5sum匹配，当它显然没有？ 这些图书馆怎么变了？
这些图书馆可能被预先链接。 RPM知道预链接。
这篇文章谈到它。
“问题”（如果你可以这么称呼的话）是rpm知道预先链接，并知道如何处理它。 正如在这个邮件列表电子邮件中简要地解释的，“rpm当-verify将预先链接 – validation，这基本上是 – 然后再重新链接和比较。”所以rpm不会validation失败的原因是它基本上正在转向closures文件的预先链接进行检查，运行validation，然后重新打开预链接。 这就是为什么rpm不会报告MD5SUM变化，但AIDE会。
链接的电子邮件是：
在星期五，2003年4月4日下午04:24:39 PM，James Ralston写道：
在2003-04-04在11：34：35-0500 Jakub Jelinek写道：
男人prelink
我最终会写更多的文档。
一个问题…
如果预先链接就地修改了实际的二进制文件和库（这似乎是从我阅读手册页的情况），那么从本质上来说，“rpm –verify”是无用的吗？ 通过预先链接修改的每个二进制文件和库都会失败大小/ md5sum / mtimetesting。
它不会失败。 rpm时–verify将prelink – validation，这实质上是–undo然后再prelinking和比较。
即使–undo被用来恢复预链接，“rpm –verify”仍然会失败（除非预先链接恢复了文件开始之前的准确的m倍，那就是）…
预链接不会修改预链接库/二进制文件的m倍。
的Jakub
另一种可能性，一般来说，可以在spec文件本身的每个文件或每个目录级别禁用单独的validation检查。 因此，虽然在这种情况下不是这样，但打包程序完全有可能禁用MD5总和检查已知由于某种原因而改变的文件。