gcc скомпилировал двоичные файлы w/different размеры?

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

Используя readelf, (readelf -a -W) я создал отчет со списком содержимого обеих сборок и сравнил их (используя Beyond Compare). Это показало, что пара дополнительных символов была извлечена из расширенных библиотек.

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

Спасибо всем за вдумчивые ответы.

objdump , вероятно, программа, которую вы ищете для сброса содержимого двоичных файлов.

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

Может помочь воспроизводимый пример:

• Используете ли вы другие внешние библиотеки?
• Вы связываете статически или динамически?
• Вы меняли такие флаги, как -O или -s?

Компиляторы DEC VMS тоже делали это. Причина в том, что оптимизатор мог бы работать лучше, чем больше свободной оперативной памяти ему приходилось работать. Очевидно, очень трудно иметь точное одинаковое количество свободной оперативной памяти, доступной при каждой компиляции.

Я помню, что в то время некоторые люди были потрясены этим. Это было особенно актуально для людей, которые любили проверять наличие изменений исходного кода, сравнивая полученные двоичные файлы. Мой совет тогда, как и сейчас, - это преодолеть. Источники вы можете "различать". Для двоичных файлов единственной гарантией является то, что оба исполняемых файла, скомпилированные из одних и тех же исходных файлов, будут выполнять то, что вы им сказали.

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

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

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

• компилятор может помещать информацию о пути / имени для файлов, задействованных при компиляции, либо для отладочной информации, либо из-за использования макроса __ FILE __ . Вполне возможно, что он может делать это для своих собственных целей, не имеющих ничего общего ни с одной из этих вещей. Если сборка происходит на разных машинах с даже немного другой структурой каталогов, это может объяснить различия в двоичном файле.
• аналогично для даты / времени сборки, хотя я ожидал, что они попадут в бинарный гораздо реже (но что я знаю?). Если бы это было способствующим фактором, вы