![Можно ли определить, какие флаги сборки использовались в предварительно собранном пакете RPM?](https://rvso.com/image/178467/%D0%9C%D0%BE%D0%B6%D0%BD%D0%BE%20%D0%BB%D0%B8%20%D0%BE%D0%BF%D1%80%D0%B5%D0%B4%D0%B5%D0%BB%D0%B8%D1%82%D1%8C%2C%20%D0%BA%D0%B0%D0%BA%D0%B8%D0%B5%20%D1%84%D0%BB%D0%B0%D0%B3%D0%B8%20%D1%81%D0%B1%D0%BE%D1%80%D0%BA%D0%B8%20%D0%B8%D1%81%D0%BF%D0%BE%D0%BB%D1%8C%D0%B7%D0%BE%D0%B2%D0%B0%D0%BB%D0%B8%D1%81%D1%8C%20%D0%B2%20%D0%BF%D1%80%D0%B5%D0%B4%D0%B2%D0%B0%D1%80%D0%B8%D1%82%D0%B5%D0%BB%D1%8C%D0%BD%D0%BE%20%D1%81%D0%BE%D0%B1%D1%80%D0%B0%D0%BD%D0%BD%D0%BE%D0%BC%20%D0%BF%D0%B0%D0%BA%D0%B5%D1%82%D0%B5%20RPM%3F.png)
Я использовал демон динамической маршрутизации 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. Если вы обнаружите, что это не так, это будет очень веской причиной для создания отчета об ошибке или иным образом связаться с дистрибьютором и сообщить о несоответствии.