LINUX.ORG.RU

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

 


1

4

Добрый вечер, граждане!

Есть одна проблема, но сначала вводная:
в наличии две совершенно идентичных виртуальных машины, с одной и той же ОС, установленной из одного и того же исошника. Для чистоты эксперимента, доступа к интернетам нет, обновляться не с чего. Всё, что можно поставить - на этом исошнике.

Так же, есть тарбол исходников некой программы на куте, система сборки CMake, будь она не ладна.

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

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

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

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

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

Заранее благодарен за различные подсказки.

P.S.: есть другие компоненты со схожим набором (тоже куте, qml плагины), но сборочная среда - qmakе - вышеозвученной проблемы нет, так что, склонен подозревать cmake.

★★★★★

Последнее исправление: cetjs2 (всего исправлений: 3)

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

В конторе работают дебилы. Отправляй им уже сгенерированные CMake makefile-ы - дебилы должны страдать.

tailgunner ★★★★★
()
Ответ на: комментарий от aol

То есть ублюдочный вариант, который обходит конкретную проблему.

А еще отправляй им компиляторы - если они попытаются собрать программу немного другим компилятором, суммы тоже не совпадут.

tailgunner ★★★★★
()
Последнее исправление: tailgunner (всего исправлений: 1)
Ответ на: комментарий от aol

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

Deleted
()

Так в чём проблемма, подифай директории сборки, посмотри в чём разница, на основе этого может и решение какое нибудь найдется.

pon4ik ★★★★★
()

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

Вообще CMake создаёт зависимости в виде ациклического графа, про какой порядок сборки речь? Или он разные мейкфайлы генерирует?

Dendy ★★★★★
()
Ответ на: комментарий от tailgunner

тут дело такое: разрабы у себя строят как хотят и на чем хотят, потом коммитят. по коммит хуку это творчество превращается в deb-src и компиляется в сборочной среде, состав которой всегда фиксирован.

Далее deb-src и полученный deb уходят в другой отдел, который только и занимается, что приемкой софта.

Они берут deb-src скармливают его у себя в такую же сборочную среду и получают свой deb. Далее они берут и сравнивают потроха моего и их пакета (не все, а только so-шки и бинари)

Так что, в этом свете предстоит нехилый финт ушами, чтобы провернуть твоё предложение...

aol ★★★★★
() автор топика
Ответ на: комментарий от pon4ik

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

aol ★★★★★
() автор топика
Ответ на: комментарий от aol

разные link.txt и еще какие-то.

Чем именно они различаются, порядком линковки обьектников или чем-то ещё? Если так, то стоит отправить багрепорт. Кстати, какая версия CMake?

Dendy ★★★★★
()

Autotools конечно же несомненно лучше CMake (лет'с зе срач бегин :) ), но система сборки тут не при чём, как минимум компилятор добавляет таймстампы при сборке, и они естественно одинаковыми не будут. Как вариант, можно их обнулять или выставлять в нужное значение после сборки бинарника

Harald ★★★★★
()
Ответ на: комментарий от aol

Версии виртуальных машин стопудово одинаковые?

// а еще, я нихрена не понял, на кой черт собирать в виртуальной машине???

И попробуй отключить всю оптимизацию в CFLAGS.

Eddy_Em ☆☆☆☆☆
()
Последнее исправление: Eddy_Em (всего исправлений: 1)
Ответ на: комментарий от Dendy

да, порядком линковки. версия cmake 2.8.9
но дистрибутив такой, что туда никакие фиксы не попадут скорее всего - на нем - сертификат фстэк и прочие препоны.

aol ★★★★★
() автор топика
Ответ на: комментарий от aol

Вопрос, в чем именно цель такой процедуры. Я лично не вижу смысла сравнивать суммы именно бинарей. Результатом деятельности разработчика является даже не тарбол с исходниками, а хеш-код ревизии.

Так что, в этом свете предстоит нехилый финт ушами, чтобы провернуть твоё предложение...

Остальное ты просил не предлагать.

tailgunner ★★★★★
()
Ответ на: комментарий от aol

не за что. Тебе может никакой инфы и не дало, но это ни о чём и не говорит(кроме того, что это крайне печально).

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

pon4ik ★★★★★
()
Ответ на: комментарий от Eddy_Em

да, стопудово. они созданы с нуля и для инсталляции использован один и тот же исо.

виртуалки для того, что не напасешься на каждый чих физических тачек. это не локалхост под диваном )

aol ★★★★★
() автор топика
Ответ на: комментарий от vertexua

Разве в бинари не пишут какой-то timestamp времени сборки?

Бывает. Вообще, сравнивать суммы пересобранных бинарей - идей сомнительная и уж точно подразумевает абсолютную идентичность сред сборки (чего у ТС явно нет).

tailgunner ★★★★★
()
Ответ на: комментарий от pon4ik

пончик, ты, наверное думаешь, я первым делом на лор попёрся? ты сильно ошибаешься.

aol ★★★★★
() автор топика
Ответ на: комментарий от aol

виртуалки для того, что не напасешься на каждый чих физических тачек

А зачем тебе физическая тачка на каждый чих? chroot делай. или тебе еще и нужны разные архитектуры?

// оптимизации-то попробовал отключать?

Eddy_Em ☆☆☆☆☆
()
Ответ на: комментарий от tailgunner

Отправляй им уже сгенерированные CMake makefile-ы

Абсолютные пути, прописанные в сгенерированных Makefile, придадут страданиям особо утончённый привкус.

i-rinat ★★★★★
()
Ответ на: комментарий от tailgunner

абсолютную идентичность сред сборки (чего у ТС явно нет).

в том-то и дело, что есть.

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

aol ★★★★★
() автор топика
Ответ на: комментарий от aol

Железо компьютеров абсолютно идентично? На них стоят абсолютно идентичные операционки, в которых запущены абсолютно идентичные виртуалбоксы?

Eddy_Em ☆☆☆☆☆
()
Ответ на: комментарий от tailgunner

Вопрос, в чем именно цель такой процедуры. Я лично не вижу смысла сравнивать суммы именно бинарей. Результатом деятельности разработчика является даже не тарбол с исходниками, а хеш-код ревизии.

Ну вот есть у тебя хеш-код ревизии, компилятора и всего остального (к примеру на нашем проекте это собрано в хеш-код манифеста в repo). И есть собранный бинарь. Как проверить, что бинарь собрался честно из этой ревизии?

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

Dendy ★★★★★
()
Ответ на: комментарий от aol

абсолютную идентичность сред сборки (чего у ТС явно нет).

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

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

tailgunner ★★★★★
()
Ответ на: комментарий от Harald

но система сборки тут не при чём, как минимум компилятор добавляет таймстампы при сборке, и они естественно одинаковыми не будут.

P.S.: есть другие компоненты со схожим набором (тоже куте, qml плагины), но сборочная среда - qmakе - вышеозвученной проблемы нет, так что, склонен подозревать cmake.

qmake вызывает другой компилятор?

sdio ★★★★★
()
Ответ на: комментарий от Dendy

Ну вот есть у тебя хеш-код ревизии, компилятора и всего остального (к примеру на нашем проекте это собрано в хеш-код манифеста в repo). И есть собранный бинарь. Как проверить, что бинарь собрался честно из этой ревизии?

Нужно раскрутить систему ровно с такими же компонентами и собрать бинарь. Я угадал?

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

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

совершенно верно. и я бы усомнился в их идентичности, если бы это была не единственная проблема!

aol ★★★★★
() автор топика
Ответ на: комментарий от aol

На одной и той же машине две компиляции (с очисткой между ними) дают одинаковые бинарники или разные?

sdio ★★★★★
()
Ответ на: комментарий от aol

я бы усомнился в их идентичности, если бы это была не единственная проблема!

Мммкей... кто-то из коллег просто решил над тобой подшутить %)

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

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

aol ★★★★★
() автор топика
Ответ на: комментарий от aol

но дистрибутив такой, что туда никакие фиксы не попадут скорее всего - на нем - сертификат фстэк и прочие препоны.

Версия CMake действительно протухшая. Так или иначе стоит понять причину. Порядок линковки действительно неопределён в CMake-скриптах, но он должен быть в моём понимании псевдослучайным, а не случайным. Пусть не в вашем проекте, но если проблема всё ещё существует (на дворе уже CMake 3.x), стоит сообщить разработчикам или починить самому.

Dendy ★★★★★
()
Ответ на: комментарий от Dendy

да, это мысль. ради эксперимента надо попробовать обновить симейк хотя бы ради того, чтобы понять, кто именно виноват )

aol ★★★★★
() автор топика

Предлагаю накатать простой helloworld, который скомпиляется просто из командной строки (без всяких cmake, qmake и даже просто make). На нем и проверить — совпадут ли контрольные суммы.

Следующим этапом будет взять этот helloworld и оформить его компиляцию при помощи cmake. Если и тут контрольные суммы совпадут, то искать проблему в мозгах.

Eddy_Em ☆☆☆☆☆
()
Ответ на: комментарий от aol

Тогда сразу переходи к helloworld'у на cmake.

Просто что-нибудь элементарное скачай с гитхаба, да скомпиляй.

А то, может, это какое-нибудь культе-шмульте говно мудрит, а ты проблему не в том месте ищешь?

Eddy_Em ☆☆☆☆☆
()
Ответ на: комментарий от aol

Помню в своё время тоже занимался сравнением link.txt, но проблемы со случайным порядком линковки не наблюдал. Возможно это давно исправлено.

Dendy ★★★★★
()
Ответ на: комментарий от sdio

действительно.. но я внес уточнение :)

таймстампы тоже никто в объектники не вкомпиливает )

aol ★★★★★
() автор топика
Ответ на: комментарий от Eddy_Em

Не, это просто CMake говно. Оно мне вообще иногда зависимости своим «ацикличным графом» в неправильном порядке выставляло. Так, что нифига не линковалось. Надоело трахаться с этим непотребством, перешел на QMake.

EXL ★★★★★
()
Ответ на: комментарий от EXL

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

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

aol ★★★★★
() автор топика

Директори на машинах одинаковые? Собирается не в дебаге? Линкер очень любит пихать абсолютные пути к библиотекам.

Kosyak ★★★★
()
Ответ на: комментарий от Kosyak

нет, в релизе. но пути одинаковые везде - машины идентичны )

aol ★★★★★
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.