LINUX.ORG.RU
решено Форум — Development  

g++ повторяемость сборки

 ,


0

3

Собираю libpqxx-3.1 и каждый раз получаю разный бинарь: 

> ./configure --enable-shared --disable-static
> make
> cp src/.libs/libpqxx-3.1.so ./
> make clean
> make
> md5sum {src/.libs/,}libpqxx-3.1.so

53931f189d7ea7bf027e24d7032a9452  src/.libs/libpqxx-3.1.so
42fc41bd8ff8add2ad17b56caf95fb12  libpqxx-3.1.so

> strip --strip-unneeded {src/.libs/,}libpqxx-3.1.so
> md5sum {src/.libs/,}libpqxx-3.1.so

c8a33471a76aefa4d311033632d4dc6d  src/.libs/libpqxx-3.1.so
0e56e3a4fbba81e976b550cb77379a8f  libpqxx-3.1.so
как это вообще так? макросов __DATE__ и __TIME__ нигде нет.

При сборке с -O0 и -save-temps diff показывает много различий вроде 

> diff a/cursor.s b/cursor.s

12366c12366
< 	.section	.gnu.linkonce.t._ZN39_GLOBAL__N_cursor.cxx_00000000_5616376313useless_trailEc,"ax",@progbits
---
> 	.section	.gnu.linkonce.t._ZN39_GLOBAL__N_cursor.cxx_00000000_B814713413useless_trailEc,"ax",@progbits
12368,12370c12368,12370
< 	.weak	_ZN39_GLOBAL__N_cursor.cxx_00000000_5616376313useless_trailEc
< 	.type	_ZN39_GLOBAL__N_cursor.cxx_00000000_5616376313useless_trailEc, @function
< _ZN39_GLOBAL__N_cursor.cxx_00000000_5616376313useless_trailEc:
---
> 	.weak	_ZN39_GLOBAL__N_cursor.cxx_00000000_B814713413useless_trailEc
> 	.type	_ZN39_GLOBAL__N_cursor.cxx_00000000_B814713413useless_trailEc, @function
> _ZN39_GLOBAL__N_cursor.cxx_00000000_B814713413useless_trailEc:
12408c12408
< 	.size	_ZN39_GLOBAL__N_cursor.cxx_00000000_5616376313useless_trailEc, .-_ZN39_GLOBAL__N_cursor.cxx_00000000_5616376313useless_trailEc
---
> 	.size	_ZN39_GLOBAL__N_cursor.cxx_00000000_B814713413useless_trailEc, .-_ZN39_GLOBAL__N_cursor.cxx_00000000_B814713413useless_trailEc
13022c13022
< 	call	_ZN39_GLOBAL__N_cursor.cxx_00000000_5616376313useless_trailEc@PLT
---
> 	call	_ZN39_GLOBAL__N_cursor.cxx_00000000_B814713413useless_trailEc@PLT
13063c13063
< 	call	_ZN39_GLOBAL__N_cursor.cxx_00000000_5616376313useless_trailEc@PLT
---
> 	call	_ZN39_GLOBAL__N_cursor.cxx_00000000_B814713413useless_trailEc@PLT
14477c14477
< 	call	_ZN39_GLOBAL__N_cursor.cxx_00000000_5616376313useless_trailEc@PLT
---
> 	call	_ZN39_GLOBAL__N_cursor.cxx_00000000_B814713413useless_trailEc@PLT
14518c14518
< 	call	_ZN39_GLOBAL__N_cursor.cxx_00000000_5616376313useless_trailEc@PLT
---
> 	call	_ZN39_GLOBAL__N_cursor.cxx_00000000_B814713413useless_trailEc@PLT
с этим, вообще, можно бороться?

P.S. проверено на gcc версий 2.95, 3.3.6, 3.4.6, 4.1.2, 4.1.3, а вот на 4.8.3 бинарник всегда одинаковый

★

Последнее исправление: Torvus (всего исправлений: 1)
← Python ругается на двоеточия
Как передать значение перменной →
Ответ на: комментарий от DELIRIUM

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

Возможно, но тогда почему он это делает не везде? Есть еще несколько плюсовых прог, которые он же собирает всегда одинаково. И плюс ко всему, как потом линкер должен будет делать деманглинг?

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

-frandom-seed

О, как! Спасибо. Не знал про этот параметр. Туда можно указать любую строку или только определенный набор? В манах, что-то, про это ничего не говорится

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

вобщем, все дело оказалось в анонимных неймспейсах. похоже придется от них отказаться (gcc 2.95 не понимает флага -frandom-seed)

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

вобщем, все дело оказалось в анонимных неймспейсах.

для повторяемости ничего анонимного не нужно.

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

Вообще-то, бинарники и верифицируемость - вещи несовместимые, так что мимо.

Это ты объясни сертификатчикам

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

Это ты объясни сертификатчикам

Я говорил про верификацию, а не сертификацию.

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

Не называйте это продакшн, пожалуйста. Продакшн - это gcc 4.8, а у вас - извращение. Но если вы решили в этой гнили работать, то конечно да - боритесь, отказывайтесь и страдайте.

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

Не называйте это продакшн, пожалуйста. Продакшн - это gcc 4.8, а у вас - извращение.

Вот и выросло поколение... Эххх. Продакшн - это то, что работает годами, ато и десятилетиями. Ибо работает - не трогай. А gcc 4.8 - это, скорее, мэйнстрим.

Но если вы решили в этой гнили работать, то конечно да - боритесь, отказывайтесь и страдайте.

Это не мое решение. Это требование заказчика (одна из поддерживаемых систем RHEL 4.1)

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

Вот и выросло поколение... Эххх. Продакшн - это то, что работает годами, ато и десятилетиями. Ибо работает - не трогай.

И правда, выросло. Наслушалось фразочек и думает что что-то знает. Продакшн - это прежде всего эффективный и поддерживаемый код. Гнилой gcc ни оптимизировать толком не умеет, ни современного языка не поддерживает. Это значит что оборудование будет работать вхолостую, а человекочасы тратиться не на улучшение кода, а на подстановку костылей чтобы хоть что-то собрать гнилым gcc.

Это не мое решение. Это требование заказчика

Понятное дело, я вас в этом решении и не обвиняю. Кто такие решения принимает, компьютер только в студенчестве видел, и это был БЭСМ. Я не понимаю как можно настолько себя не уважать чтобы в такой помойке работать. Я, каюсь, сам работал (дайте угадаю, вы тоже пошли после института в совковую контору где работал препод с вашей кафедры, прикладной математики или чего-то похожего? ибо ни один нормальный человек с опытом в такое по собственной воле не нырнёт) так что не думайте что я этой кухни не знаю - и после очередного «требования заказчика» ушёл на в два раза большую зарплату, писать код который работает, а не существует как приложение к бумажке.

slovazap ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.
← Python ругается на двоеточия
Development
Как передать значение перменной →