c - `ar` 库覆盖时间戳

Question

.a 存档格式 header 需要时间戳。这导致我在重建静态库时头疼无数，主要是因为我无法准确地重现原始二进制文件。

例如(这是在我的 Mac 上，但同样的事情发生在 x64 linux 上):

$ cat foo.h
int foo();
$ cat foo.c
#include "foo.h"
int foo() { return 3; }
$ gcc -fno-pic -m64 -arch x86_64 -I/usr/local/include -O3 -c foo.c -o foo.o -fpic
$ ar rcs libfoo.a foo.o
$ md5 libfoo.a
MD5 (libfoo.a) = 0d0e6606185de4e994c47f4a0e54c1c4
$ mv libfoo.a libfoo.a1
$ ar rcs libfoo.a foo.o
$ md5 libfoo.a
MD5 (libfoo.a) = 22a69d42e1325ae8f978c2a18a4886da    

为了向自己证明唯一的区别是时间，我根据 hexdump 进行了比较:

$ diff <(hexdump libfoo.a) <(hexdump libfoo.a1)
2,3c2,3
< 0000010 20 20 20 20 20 20 20 20 31 33 31 31 30 34 33 30
< 0000020 38 36 20 20 35 30 31 20 20 20 32 30 20 20 20 20
---
> 0000010 20 20 20 20 20 20 20 20 31 33 31 31 30 34 32 38
> 0000020 37 31 20 20 35 30 31 20 20 20 32 30 20 20 20 20

如果您使用 header 格式进行反向求解，则对应于时间字段。

Manpage 没有说明是否可以覆盖 header 中的时间戳。有什么想法吗？

编辑:是的，可以返回并物理破解文件以使用任意时间戳。是的，可以更改程序的行为。考虑到周围的情况，并非所有这些都是严格的技术性质，手动更改时间戳的工具是 Not Acceptable ，ar 的修改版本也不是，也不是与实际系统混淆时间。

编辑:在这种情况下，我必须证明，在构建路径没有任何 Not Acceptable 偏差的情况下，可以从源代码生成二进制文件。在某些行业(例如金融)，这显然是一种标准做法。手动更改时间戳的工具是 Not Acceptable (因为使用了不在原始构建路径中的特殊工具)。 ar 的手动版本是 Not Acceptable (类似问题)。更改系统时钟的问题在于构建必须完美协调(这是一个长达一小时的构建，包含大量库和二进制文件)。可接受的解决方案包括:

• 标记 AR 或其他可以覆盖库中时间戳的程序
• 执行此操作的现有(年龄 > 1 岁)工具
• 在进行链接时可以覆盖来自 ar 的时间戳的 GCcflags

Answer 1

在 ar 中使用“确定性模式”。请参阅手册中 ar 的选项“D”。

me@mybox:~$ rm libfoo.a; touch foo.o; ar rcsD libfoo.a foo.o; md5sum libfoo.a
3ecae045133ff919d1e42f6050ef56be  libfoo.a
me@mybox:~$ rm libfoo.a; touch foo.o; ar rcsD libfoo.a foo.o; md5sum libfoo.a
3ecae045133ff919d1e42f6050ef56be  libfoo.a

如果您之后使用ranlib，请确保您使用的是ranlib -D；否则 ranlib 将放回时间戳。