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

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

Я использовал демон динамической маршрутизации Quagga на виртуальной машине CentOS 6. Я хотел бы использовать функцию, которая доступна только в том случае, если RPM был собран с флагом --multipath=X. RPM, который я использую, уже был собран и получен из репозитория CentOS.

Есть ли способ узнать, был ли RPM собран с этим флагом, или мне придется собирать его из исходников и самостоятельно указывать этот флаг?

Я загрузил исходный пакет RPM и заметил, что в прилагаемом файле спецификаций параметр multipath установлен на 64. Поэтому я мог бы просто собрать его сам, если бы мне это было нужно.

решение1

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

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

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

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

решение2

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

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

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

Команда:показать версию

Показать текущую версию Quagga и информацию о хосте ее сборки.

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

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

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

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

Связанный контент