![É possível determinar quais sinalizadores de construção foram usados em um pacote RPM pré-construído?](https://rvso.com/image/178467/%C3%89%20poss%C3%ADvel%20determinar%20quais%20sinalizadores%20de%20constru%C3%A7%C3%A3o%20foram%20usados%20%E2%80%8B%E2%80%8Bem%20um%20pacote%20RPM%20pr%C3%A9-constru%C3%ADdo%3F.png)
Tenho usado o daemon de roteamento dinâmico Quagga em uma VM CentOS 6. Gostaria de usar um recurso que só será acessível se o RPM tiver sido criado com o --multipath=X
sinalizador. O RPM que estou usando já foi compilado e obtido no repositório CentOS.
Existe uma maneira de descobrir se o RPM foi construído com esse sinalizador ou preciso compilar a partir do código-fonte e fornecer esse sinalizador sozinho?
Baixei o pacote fonte RPM e percebi que no arquivo de especificações fornecido o parâmetro multipath está definido como 64. Então, eu poderia construí-lo sozinho, se precisasse.
Responder1
Em geral, os sinalizadores específicos do compilador usados para construir um binário do espaço do usuário não são preservados dentro do binário. Não há razão para que sejam.
Normalmente, você pode descobrir qual compilador e versão do compilador foi usado para construir o binário examinando-o, crt0
mas mesmo essas informações podem ser ofuscadas usando um arquivo crt0
.
Supondo que não seja um binário estático, você poderá inferir opções específicas de tempo de compilação/construção examinando quais objetos compartilhados ("".so") o binário está usando e quais funções de cada objeto compartilhado o binário está usando.
Se você tiver o código-fonte, poderá examinar a listagem de desmontagem e determinar com precisão razoável se um sinalizador de opção específico foi usado quando o binário foi construído.
Responder2
Como disse @fpmurphy, os sinalizadores do compilador geralmente não são preservados no binário. E as opções de tempo de construção como --multipath=X
são opções mais prováveis para o ./configure
script, então elas podem fazer algo como controlar a geração de um config.h
arquivo, que então participará do processo de construção sem necessariamente afetar os sinalizadores do compilador.
Mas quando um programa tem muitas dessas opções, háàs vezes(nem sempre) uma maneira de descobrir o estado das opções relevantes de tempo de construção. Se essas informações estiverem disponíveis, muitas vezes elas podem ser exibidas por meio de programname --version
uma opção semelhante que exibe informações de versão.
Eu não conheço Quagga, masa seção de documentação que descreve seus comandos do modo Terminaltem um comando de aparência promissora:
Comando:mostrar versão
Mostra a versão atual do Quagga e as informações do host de compilação.
As "informações do host de compilação" podem incluir informações sobre as opções de tempo de compilação. Ou talvez não. Mas se eu não tivesse fontes de informação mais fáceis, esse seria um dos primeiros lugares que procuraria.
Se o software estiver empacotado e você puder encontrar o pacote fonte correspondente, a idéia geral é que o pacote fonte inclua toda a configuração em tempo de construção necessária para produzir um binário que seja pelo menos 100% funcionalmente equivalente àquele distribuído no pacote correspondente. pacote(s) binário(s) da mesma distribuição. Se a distribuição estiver usando as novas técnicas de "construções reproduzíveis", o binário resultante pode até ser idêntico bit por bit.
Portanto, o pacote fonte (e no caso de um RPM, seu .spec
arquivo em particular) é uma boa fonte de informações sobre opções de tempo de construção usadas no pacote binário correspondente.
Supondo que o RPM de origem cujo .spec
arquivo você verificou também veio do repositório do CentOS e tinha a mesma versão do seu binário, a suposição padrão seria que sim, --multipath=64
foi usado na produção do RPM binário. Se você achar que isso não é verdade, seria um bom motivo para fazer um relatório de bug ou entrar em contato com o distribuidor e relatar a discrepância.