Можно ли определить, какие флаги сборки использовались в предварительно -собранном RPM-пакете?

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

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

Предполагая, что это не статический двоичный файл, вы можете сделать вывод о конкретных параметрах времени компиляции/сборки, изучив, какие общие объекты (".so" )использует двоичный файл и какие функции из каждого общего объекта используются. бинарный используется.

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

Как сказал @fpmurphy, флаги компилятора обычно не сохраняются в бинарном файле. И параметры времени сборки -, такие как --multipath=X, скорее всего, являются параметрами для сценария ./configure, поэтому они могут делать что-то вроде управления генерацией файла config.h, который затем будет участвовать в процессе сборки, не обязательно затрагивая флаги компилятора вообще.

Но когда в программе много таких опций, есть иногда(не всегда )способ узнать состояние соответствующих опций -времени сборки. Если эта информация доступна, ее часто можно отобразить с помощью programname --versionили аналогичной опции, отображающей информацию о версии.

Я совсем не знаком с Quagga, но в разделе документации, описывающем его команды режима терминала , есть одна многообещающая -выглядящая команда:

Command: show version

Show the current version of Quagga and its build host information.

«Информация о хосте сборки» может включать только информацию о параметрах -времени сборки. А может и нет. Но если бы у меня не было более простых источников информации, это было бы одним из первых мест, где я бы поискал.

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

Таким образом, исходный пакет (и, в случае RPM, его .specфайл, в частности ), являются хорошим источником информации об опциях времени сборки -, используемых в соответствующем бинарном пакете.

Предполагая, что исходный RPM, чей файл .specвы проверили, также поступил из репозитория CentOS и имел ту же версию, что и ваш двоичный файл, стандартное предположение было бы таким: да,--multipath=64был использован при создании бинарного RPM. Если вы обнаружите, что на самом деле это не так, это будет очень хорошей причиной, чтобы сообщить об ошибке или иным образом связаться с дистрибьютором и сообщить о несоответствии.