问题标签 [binary-reproducibility]
For questions regarding programming in ECMAScript (JavaScript/JS) and its various dialects/implementations (excluding ActionScript). Note JavaScript is NOT the same as Java! Please include all relevant tags on your question; e.g., [node.js], [jquery], [json], [reactjs], [angular], [ember.js], [vue.js], [typescript], [svelte], etc.
build - 如何存储 CMake 构建设置
在尝试构建使用 CMake 的项目时,通常有很多开关可以启用/禁用。
您如何存储某些用户所做的构建设置以使构建可在另一台机器上重现?是否有某种导出功能,或者您只是复制构建(缓存)文件夹?
java - 如何使 Android 应用程序具有可重现的构建?
根据我的经验,为同一个 Android 应用程序重新编译源代码不会每次都生成相同的二进制文件。可重现的构建对开发人员非常有用,但我认为可重现构建过程最重要的好处是安全性。在开源 Android 应用程序中,我们如何验证生成的二进制文件 ( .apk
) 是否真的是从经过审查的源代码编译而来的?有没有办法从 Android SDK 或 Java 生成可重现的构建?
c# - 源代码没变,但是每次重建项目(Visual Studio C#),输出的exe文件内容都不一样
我创建了一个空的 WPF 项目(Visual Studio 2010 或 2013,C#),我发现即使我没有修改源代码,只是重新构建项目,输出的 exe 文件内容不同。谁能告诉我为什么?
在同一台构建机器上,我想要“当源代码没有修改时,我重新构建项目,重新构建的模块(dll,exe)是相同的(二进制内容相等)”谁能告诉我如何获得这个目标?
c - Yagarto (GCC, Win32) 在不同的 PC 上以不同的方式编译相同的代码
我在 Windows 上使用 Yagarto 工具链来编译大约 100K 行代码的代码库。
我们有两台开发电脑。然而,尽管具有相同的工具链和构建相同的源代码,它们各自构建的二进制文件略有不同。
我使用 MD5 检查了我们有相同的编译器二进制文件、相同的系统头文件,并且我们正在编译相同的源代码,将相同的命令行传递给 GCC,但存在细微的差异。
在我们代码库中的 81 个目标文件中,有 77 个编译完全相同;和四个有细微的差别。没有功能上的区别,但由于我们将支持编译的二进制文件,我想深入了解这个问题。
“arm-elf-gcc.exe”的日期为 2006 年 7 月 16 日。“arm-elf-gcc -v”的输出为:
以下是不同生成代码的列表文件中的示例:
在这两种情况下,只是堆栈帧中变量的顺序不同;除了变量的顺序不同之外,所有代码都是相同的。(列表文件上的“diff”只显示与 #40 相对应的各种其他行与 #28 等交换)。
这种变化显然是无害的(虽然我想知道为什么),但是在另外两个目标文件中,文本段的大小实际上在一个版本中大了 4 个字节,并且变量在堆栈帧,有几个不同的指令。
一台 PC 是运行 Windows 2000 的 Intel Core 2 Duo,另一台是运行 Windows 7 的 AMD X4。每台 PC 都能可靠地复制相同的构建,但其中一台 PC 的构建与其他 PC 不同。
GCC 是否可能会根据实际用于构建的 CPU 进行不同的优化?(不是目标 CPU)。或者还有什么可能导致这种差异?
c - 为什么只有注释更改的两个程序二进制文件在 gcc 中不完全匹配?
我创建了两个 C 程序
程序 1
/li>节目二
/li>
AFAIK,编译时,编译器(gcc)应该忽略注释和多余的空白,因此输出必须相似。
但是当我检查输出二进制文件的 md5sum 时,它们不匹配。我也尝试使用优化进行编译,-O3
但-Ofast
它们仍然不匹配。
这里发生了什么?
编辑:确切的命令和 md5sum 是(t1.c 是程序 1,t2.c 是程序 2)
是的,md5sums 在具有相同标志的多个编译中匹配。
顺便说一句gcc (GCC) 5.2.0
,我的系统是Linux 4.2.0-1-MANJARO #1 SMP PREEMPT x86_64 GNU/Linux
c++ - 使用 Visual Studio 的可重现构建 - 目标文件差异
我试图确保两台不同的机器产生相同的构建。我试图使环境尽可能相似,但我仍然看到生成的 .obj 和 .exe 文件存在一些差异。我已经能够排除嵌入式路径差异和时间戳。我还确保了最少的代码示例(例如 hello world 程序实际上会生成相同的二进制文件)。
目前一些目标文件是相似的,而另一些则不是。如果我使用 diff 来查看不同之处,dumpbin /all
我会看到如下差异:
在许多SECTION HEADER
. 在没有 100% 证明的情况下,在我看来,每个差异都是在另一个目标文件的转储输出的另一个部分中出现的一行。所以事情似乎有不同的顺序。(但请注意,这只是我目前的假设——我可能错了。)
关于如何从这里继续前进以及原因可能是什么的任何提示?建立/链接顺序?
我还看到微软这样写:
注意:不能保证 Visual C++ 在连续构建时生成相同的源文件时会生成相同的二进制映像。但是,您可以保证 EXE(或 DLL)在执行时的行为方式完全相同,所有其他条件都相同。
但我仍然想知道在我的具体情况下发生了什么。在我的情况下,同一台机器上的连续构建提供相同的构建。
python - python中的可重现构建
我需要发布一个 Python 脚本的编译版本,并且能够证明(使用哈希)编译的文件确实与原始文件相同。
到目前为止,我们使用的是一个简单的:
问题是这是不可重现的(不确定波动因素是什么,但 2 次执行不会给我们相同的 .pyc 相同的 python 文件)并迫使我们始终发布相同的编译版本,而不是仅仅给出构建脚本给任何人以生成新的编译版本。
有没有办法做到这一点?
谢谢
r - Rscript和简单图
显然有同样问题的人:http ://r.789695.n4.nabble.com/Two-questions-on-R-and-cairo-Cairo-td2318527.html
我想知道为什么我使用 Rstudio、Rscript 或仅来自终端的 R 控制台从同一命令中获得不同的结果。我使用的代码很清楚:
从终端使用 Rscript 或 R 命令提示符获取的图像。(cmd:Rscript script.R)
[编辑 1] 检查我生成的文件时,我实际上有不同的大小和属性:
[编辑 2:在这里我需要更多帮助] 从 sinQueso 的评论中回答:结果
从 Rstudio,我得到:
我检查了一下,我只是无法使用以下命令加载 cairo:
(已安装 libcairo2-dev)
所以我尝试了:
从 R 控制台,但即使我加载开罗,我显然仍在使用 Xlib。
sessionInfo:唯一的区别:在 RStudio 中加载了 tools_3.3.2
c++ - C ++:在带和不带“-g”的剥离后获得相同的二进制文件
我正在尝试改进一个 1GB 共享库的构建时间,该共享库是从 ~400 个依赖项构建的,然后剥离到 100MB。依赖项没有被剥离,所以我认为如果我之前预先剥离依赖项(或者只是-g
从一开始就构建它们),它可能会构建得更快。测试这个库是一项很大的工作,但如果新的构建过程产生完全相同的二进制文件,我可以避免测试。
我为此做了一个小测试,只有一个 C++ 文件lib.cc
:
这是一个Makefile:
这是我用来比较二进制文件的脚本:
我得到的二进制文件之间的差异大约是 10 个字节。有什么办法可以避免这种差异,并让这两种方法产生相同的二进制文件?
linux - 如何防止 cargo fmt 更改已编译的二进制文件?
我用 rustfmt 0.4.1-stable 重新格式化了我的代码库,并且有一个很难用肉眼检查的巨大差异。
很久以前,我在cargo fmt
产生巨大差异后遇到了类似的问题。当时,我通过以下方式解决了它:
差异只有几个字节,看起来像一个时间戳,但这次hexdump
/objdump
输出之间的差异是巨大的。
代码不同,例如:
如何使构建前后可重现cargo fmt
?