Любителям CMake посвящается

А если на другой машине например выставить hostname, может IP, ... такие же как и на первой? Из-за чего-то ведь меняется содержимое бинарника?

There are often many swiches to enable/disable when trying to build a project that uses CMake.

How do you store the build settings made by some user to make a build reproduceable on another machine?

http://stackoverflow.com/questions/17588517/how-to-store-cmake-build-settings

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

Лучше спросить в IRC'е #marble на freenode там авторы (Dennis Nienhüser, Torsten Rahn и Bernhard Beschow) тусуются постоянно.

А вы vbidiff'ом смотрели, в каких именно байтах отличия?

Правильно ли я понял, что вы сознательно нарушаете LGPL, иначе где ссылка на репу?

Смотрели hexdiff-ом, readelf-ом такое ощущение что порядок линковки блоков внутри so файла разный. Вплоть до GNU_EH_FRAME offset.

нет не нарушаем. Собираем с бранча: origin/sok-2012-plasma-active потому что не все наши коммиты прошли в upstream и нет времени добить эту тему

Я уже писал, что mainstream marble наверняка имеет те же самые проблемы.

Там только Qt юзается? KDE-говно не тянется?

Если интересно, это проект marble, который мы по неволе расширяем.

Странно, что для Marble вы используете очень старую версию CMake, этому есть обьективные причины? Marble ведь активно развивается сам по себе. А QMake вообще неинкрементальная система сборки, никогда ей не была и уже не будет, её потолок это сборка самой Qt с нуля.

А точно нету какой-то разницы в способе сборки? Например, кол-во потоков.

Странно, что для Marble вы используете очень старую версию CMake

номера версий ПО продиктованы дистрибутивом, который мы используем.. весь производный софт должен собраться в изолированном окружении без сторонних пакетов.

точно. грубо говоря, единственная разница - link.txt :)

кдешное говно отключается дефайном -DQTONLY=YES - именно так мы его и собираем..

какого черта они различаются, и как это вылечить?

Аутист, что ли? А тебя не напрягает, что яйца на разной высоте висят? Срочно беги к хирургу, исправлять!

Считаем контрольные суммы - они различаются!

Они будут различаться даже при одинаковом порядке сборки.

А если ты еще и -jN для N > 1 будешь использовать, то никакого порядка вообще никто тебе никогда не гарантирует.

В конторе приемка софта происходит по вычислению контрольной суммы бинаря, пришедшего от разработчика и сравнению её с контрольной суммы бинаря, полученного проверяющим при пересборке.

Принести бочку керосина, разлить, поджечь. Выбегающих из конторы отстреливать с безопасного расстояния.

понатыкай strip для бинарей, библиотеки (so-шки) собирай через ar. а то в бинарь могут улететь даты объектников, даты исходников да и вообще мало-ли чего..__DATE__ и подобные макросы в исходниках чего стоят :)

кстати, если режимная сборка, то это недопустимо в вирт.машинах - только на реальном, серт.железе

Я думаю, что адекватные люди не думают за других о чём те думают:)

Избитая же тема - делаешь минимальный пример на котором поведение воспроизводится и кидаешь людям которые шарят. А не включаешь астрал моде он и вброс про НИИ.

Они будут различаться даже при одинаковом порядке сборки.

В целом повторяемость сборки — это не пустой звук, а процесс сборки — не необъяснимое волшебство, поэтому такого не должно происходить.

У нас cmake как раз используется именно для получения повторимых сборок, проблем никогда не было. Сборочных машин несколько, используется параллельная сборка.

Я бы первым делом сравнил сгенерённые Makefile, если они разные - проблема действительно в cmake - либо он у вас действительно слишком старый, либо пишите баги.

В целом повторяемость сборки — это не пустой звук,

Еще один аутист, которому яйца мешают?

поэтому такого не должно происходить.

Должно. И компилятор, и линкер имеют полное право использовать случайные или псевдослучайные процессы. И чем дальше в оптимизации, тем больше это будет необходимо. Давно доказано, что рандомизированные эвристики работают как правило лучше детерминированных. Что, ради таких убогих аутистов, как ты, брать чексумму исходников в качестве seed каждый раз?

Царь, ты что ли? Прости, батюшка, не признал. Кланяюсь в пол.

я уже с дивана вещаю - завтра ради эксперимента засуну туда новый cmake

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

И компилятор, и линкер имеют полное право использовать случайные или псевдослучайные процессы.

Знакомая лексика... это не ты - автор патчей к GCC и LLVM?

Может им патченый md5sum в PATH подсунуть?

А если ты еще и -jN для N > 1 будешь использовать, то никакого порядка вообще никто тебе никогда не гарантирует.

Порядок исполнения отдельных команд не гарантирует. А порядок аргументов в каждой команде гарантировать обязан. И линковщик здесь не исключение.

номера версий ПО продиктованы дистрибутивом, который мы используем.. весь производный софт должен собраться в изолированном окружении без сторонних пакетов.

Если в свежем CMake проблема исправлена, то засуньте его себе в изолированное окружение и собирайте при бутстрапе.

да, так и придется делать.. завтра после эксперимента всё расскажу :)

Я видел, поэтому и написал что у нас тоже используются разные хосты.

Должно. И компилятор, и линкер имеют полное право использовать случайные или псевдослучайные процессы.

Но только пока не используют. А если использовали бы, проблема бы решалась возможностью подсунуть один и тот же seed для генератора случайных чисел. Он бы тогда генерировал одинаковые числа.

А ты иди и помедитируй над опцией gcc -frandom-seed=

Но только пока не используют.

Используют. Много и с удовольствием.

проблема бы решалась возможностью подсунуть один и тот же seed для генератора случайных чисел

Ну так и подсовывай, аутист. -frandom-seed=блаблабла.

Только вот это не поможет в случае со случайным порядком сборки (и -jN). На уровне .o файлов детерминизма еще можно добиться, а вот в процессе линковки фиг тебе.

А порядок аргументов в каждой команде гарантировать обязан.

С какой это плешивой радости?!?

Ну так и подсовывай, аутист. -frandom-seed=блаблабла.

ТС, попробуй, что ли, подсунуть! Вдруг этого хватит.

Только вот это не поможет в случае со случайным порядком сборки

Ну так может ещё куда-то надо аналогичную опцию подсунуть.

и -jN

Ну этого ТС, я думаю, и сам не применяет, раз такое дело.

А порядок аргументов в каждой команде гарантировать обязан.

С какой это плешивой радости?!?

Потому что в общем случае порядок аргументов влияет на результат выполнения.

Только вот это не поможет в случае со случайным порядком сборки (и -jN). На уровне .o файлов детерминизма еще можно добиться, а вот в процессе линковки фиг тебе.

У вас какая-то каша в голове. Причём здесь порядок сборки вообще? Когда очередь доходит до линковки все обьектники уже собраны, в каком порядке они собирались никого не интересует. Изначальная проблема была давно озвучена: случайный порядок аргументов линкера. Мейкфайлы и многопоточная сборка к этой теме отношения не имеют.

Когда очередь доходит до линковки все обьектники уже собраны, в каком порядке они собирались никого не интересует.

Линкер может разместить секции из .o файлов в памяти в любом порядке, как его припрет. Особенно если это gold. При одних и тех же аргументах может быть разный результат.

Изначальная проблема была давно озвучена: случайный порядок аргументов линкера. Мейкфайлы и многопоточная сборка к этой теме отношения не имеют.

Порядок аргументов легко может зависеть от порядка исполнения правил.

Сравнивать бинарники, собранные из одинаковых сорцах, но в разное время глупо: где-то может неприметно затаится такая штука, как timestamp. Так что ССЗБ.

По теме — не знаю. Возможно внутри cmake использует хеш-мапы для разруливания зависимостей. А у самих хеш-мап порядок ключей часто рандомизирован при обходе. Вот и выходим на разный порядок сборки

Порядок аргументов легко может зависеть от порядка исполнения правил.

В CMake уж точно не может, порядок определяется на этапе генерации.

Если такое происходит, то это симптом неверно расставленных зависимостей в системе сборки и должен быть исправлен.

Вообще система сборки общего назначения не может знать о том какие утилиты она запускает и тем более манипулировать аргументами.

А ты иди и помедитируй над опцией gcc -frandom-seed=

А ты - над сравнением компиляторов stage2 и stage3.

В CMake уж точно не может, порядок определяется на этапе генерации.

Объектники, предназначенные для сборки в одну библиотеку, имеют одинаковый приоритет сборки, поэтому теоретически могут быть собраны в разном порядке даже при однопоточной сборке, не говоря уже о -jN.

Попробуйте для начала сравнить выхлопы make VERBOSE=1 на разных машинах.

Речь про порядок аргументов линковщика, а не порядок сборки.

Ну так Вам и ответили:

Порядок аргументов легко может зависеть от порядка исполнения правил.

Изменить процедуру приёмки не представляется возможным. Вдоль, бочку и бежать оттуда не предлагать ;)

Предлагаю попросить заказчика отдельно оплатить искусственно созданные (неоправданные) сложности. Если не согласится, самому придумать какую-нибудь ерунду того же уровня (попросить выделить тебе отдельную приемочную среду с круглосуточным доступом на отдельной машине).

Если заказчик придумал глупость и предлагает тебе преодолевать ее за свой счет, сделай так, чтобы это было за его счет. В конце концов заказчику результат нужен даже больше, чем тебе.

P.S. Ты хоть предоплату взял с него?

А я ответил, что не может, поэтому дальнейшие разговоры про порядок сборки бессмысленны. Я прекрастно знаю как работает многопоточная сборка, но к данной теме это отношения не имеет.

чуваак, без минимального примера - это поиск фиг знает чего, тебя реально так ломает потратить 5 минут и сделать аналогичный проект, с сорцами FooBar?

Если бага есть - она воспроизведется:)

Как ты сорцы вытаскиваешь на эти 2 идеально идентичные системы?

Какие ресурсы используются в программе, помимо файлов исходных данных?

Используется ли где то команда configure_file ?

Воу, спасибо.

Так вот, вопрос как раз в этом: какого черта они различаются, и как это вылечить?

собирай в один поток, для простой make это -j, для QMake я не помню. Вроде-бы также.

В конторе приемка софта происходит по вычислению контрольной суммы бинаря, пришедшего от разработчика и сравнению её с контрольной суммы бинаря, полученного проверяющим при пересборке.

ваще-то подпись(ЭЦП) проверять нужно. И не бинаря, а исходников или пакета.

Идентичные системы сборки дают идентичные результаты.

только если ты в один поток собираешь. Если в два и более, возможны варианты. Тоже самое с сжатием файлов.