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

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

6 голосов
/ 29 июня 2009

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

Ответы [ 6 ]

8 голосов
/ 29 июня 2009

Дата сборки включена в версию, см. 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 из предыдущей строки, вы сможете избавиться от зависимости времени сборки.

5 голосов
/ 01 августа 2009

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

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

2 голосов
/ 13 января 2014

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

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

1 голос
/ 29 июня 2009

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

0 голосов
/ 29 июня 2009

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

0 голосов
/ 29 июня 2009

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

...