По крайней мере, в описанном выше случае xscreensaver
использовался как блокировщик экрана.
Если блокировщик экрана не установлен, система запрашивает его -, если только блокировка экрана не отключена в LXQt > Настройки > Настройки LXQt > Настройки сеанса > Блокировка экрана перед приостановкой/гибернацией-с помощью -, поставив там галочку.
Как правило, определенные флаги компилятора, используемые для создания двоичного файла пользовательского пространства, не сохраняются в двоичном файле. Нет причин для того, чтобы они были.
Обычно вы можете выяснить, какой компилятор и версия компилятора использовались для сборки двоичного файла, изучив его 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. Если вы обнаружите, что на самом деле это не так, это будет очень хорошей причиной, чтобы сообщить об ошибке или иным образом связаться с дистрибьютором и сообщить о несоответствии.