1

Я стараюсь, чтобы две разные машины производили идентичные сборки. Я попытался сделать среду максимально похожей, но я все еще вижу некоторые отличия в сгенерированных файлах .obj и .exe. Я смог исключить встроенные различия пути и временные метки. Я также гарантировал, что минимальные примеры кода (например, приветственная мировая программа на самом деле производят идентичные двоичные файлы).Воспроизводимые сборки с Visual Studio - разница между файлами объектов

В настоящее время некоторые объектные файлы похожи, а другие нет. Если я смотрю на тех, которые отличаются использованием различий в dumpbin /all я вижу различие, как это:

> COMDAT; sym= "public: static int const std::numeric_limits<long double>::max_exponent" ([email protected][email protected]@[email protected]@2HB) 

< COMDAT; sym= "public: static int const std::_Locbase<int>::collate" ([email protected][email protected]@[email protected]@2HB) 

во многих SECTION HEADER. Не доказав это на 100%, мне кажется, что каждая разница - это строка, которая встречается в другом разделе в выгруженном выходе из другого объектного файла. Так что все выглядит по-другому. (Но обратите внимание, что это только мое текущее предположение - возможно, я ошибаюсь.)

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

Я также видел, что Microsoft пишет this:

ПРИМЕЧАНИЕ: Там нет никакой гарантии, что Visual C++ будет генерировать тот же двоичный образ при создании тех же исходных файлов на последовательных сборок. Тем не менее, вам гарантировано, что EXE (или DLL) будет вести себя точно так же, как и при выполнении, при прочих равных условиях.

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

+0

Вряд ли когда-либо получат идентичные двоичные файлы с разных машин (или с одной и той же машины). Если вы конкретно не указываете, какие части должны быть идентичными (и что вы собираетесь делать с этой информацией), на этот вопрос можно ответить только: невозможно. – IInspectable

+0

@IInspectable - для меня было бы достаточно доказать это для одной пары сборки - мне не нужны непрерывные бинарные совпадения. Но в целом это проблема, которую гораздо труднее решить в Windows, чем Linux? Ограничения в VS? Я видел несколько случаев, когда работа продвигалась по воспроизводимости сборки на Linux - например, пакеты debian. – Zitrax

+0

Как вы уже цитировали, Visual Studio гарантирует одинаковое поведение, и все. Вы все еще не объяснили, почему вам нужно знать, идентичны ли 2 бинарных файла (для некоторого определения * одинаково *). Не зная, зачем вам нужна эта информация, трудно дать удовлетворительный ответ. – IInspectable

ответ

1

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

В журнале сборки указаны разные версии для rc.exe (компилятор ресурсов). Оказывается, это часть комплектов Windows, которые поставляются с VS. Однако, если вы устанавливаете две версии visual studio, они будут делиться rc, в то время как компилятор и компоновщик являются отдельными.

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

Смежные вопросы