Как собрать одно и то же ядро ​​Linux дважды и получить одинаковую контрольную сумму

Question

Я ищу, возможно ли собрать одно и то же ядро ​​Linux (те же исходники, то же окружение, те же параметры, тот же компилятор) и получить ту же контрольную сумму. Кто-нибудь знает, как это сделать?

Answer 1

Дата сборки включена в версию, см. Init version.c:

const char linux_banner[] =
    "Linux version " UTS_RELEASE " (" LINUX_COMPILE_BY "@"
    LINUX_COMPILE_HOST ") (" LINUX_COMPILER ") " UTS_VERSION "\n";

и UTS_VERSION определен в include / linux / compile.h:

/* This file is auto generated, version 1 */
/*  PREEMPT */
#define UTS_MACHINE "arm"
#define UTS_VERSION "#1 PREEMPT Mon Jun 29 10:49:17 CEST 2009"
#define LINUX_COMPILE_TIME "10:49:17"
#define LINUX_COMPILE_BY "cynove"
#define LINUX_COMPILE_HOST "jp"
#define LINUX_COMPILE_DOMAIN "evonyc"
#define LINUX_COMPILER "gcc version 4.3.2 (crosstool-NG-1.4.0) "

compile.h генерируется скриптами /mkcompile_h, где вы найдете следующую строку:

UTS_VERSION="$UTS_VERSION $CONFIG_FLAGS `LC_ALL=C LANG=C date`"

Удалив date из предыдущей строки вы сможете избавиться от зависимости времени сборки.

Answer 2

Ответ Shodanex правильный, но неполный. После некоторых исследований я обнаружил, что двоичный файл ядра Linux встраивает ramfs по умолчанию, что является еще одной причиной различий между компиляциями двух ядер (дата встраивания заголовка CPIO RAMFS). Невозможно отключить эту функцию, но можно предоставить ramfs по умолчанию. Когда вы делаете это, вы получаете точно такую ​​же контрольную сумму.

Спасибо. Ваши ответы очень помогают мне решить мою проблему.

Answer 3

@gsempe, вы хотели бы посмотреть на это: "Сделать сборку ядра детерминированной" ref. http://lwn.net/Articles/437864/

можно избавиться от определенных источников шума (шум... в глазах смотрящего;-)

Answer 4

Даже простой привет мир, скомпилированный дважды, приводит к разным двоичным файлам. Каким-то образом компоновщик добавляет некоторую информацию, которая изменяется в каждой сборке.

Answer 5

Предположительно, сборка ядра в одной и той же среде приведет к одной и той же контрольной сумме. Итак, тот же компилятор (та же версия того же компилятора), точно такой же источник, те же зависимости (если это применимо даже к компиляции ядра) и т. Д.

Answer 6

Самый быстрый способ проверить это сделать, сделать копию, очистить, а затем сделать снова. Если контрольная сумма совпадает, то это возможно. Если нет, то это говорит о том, что Make каким-то образом изменяет некоторые исходные файлы (нумерация сборок, дата сборки и т. Д.)