arquivo de especificações do GCC: como obter o caminho da instalação

9

Em vez de dar -Wl,-rpath=$HOME/local/gcc52/lib64 a cada invocação do GCC 5.2 que eu construí da fonte, modifiquei o arquivo spec desta forma:

*link_command:
%{!fsyntax-only:%{!c:%{!M:%{!MM:%{!E:%{!S:    %(linker) -rpath=%:getenv(HOME /local/gcc52/lib64) ...

Mas isso depende da minha instalação específica em $HOME/local/gcc52 . Existe uma maneira melhor de se referir ao caminho de instalação do próprio GCC invocado?

Esta página de manual não me ajudou muito:

por nodakai 02.12.2015 в 13:33
fonte

2 respostas

2

Até onde eu sei, o GCC é muito dependente da pasta de instalação para a qual foi compilado. Eu construo porta-ferramentas de cross-compilação RTEMS com muita frequência, e uma das primeiras coisas que aprendi foi que há muitos lugares no compilador cruzado gerado onde o prefixo de instalação (ou seja, o que foi passado para --exec-prefix ) é "queimado" em.

"Learned" - como em, eu tentei mover a pasta do compilador para um caminho diferente, e todo o inferno começou: -)

Meu ponto: modificar arquivos specs para fazê-los apontar para caminhos na sua instalação parece absolutamente normal, no que diz respeito ao GCC.

    
por ttsiodras 15.10.2017 / 00:30
fonte
0

Quando você está compilando o GCC, precisa passar o prefixo que deseja para configure . Nesse momento, você também pode dar a opção --with-specs . Com base em minhas experiências, a opção --with-specs='%{!static:%x{-rpath='$prefix'/lib64} %x{-enable-new-dtags}}' (onde $prefix should be replaced by the same path you pass to - prefix ') funciona (você precisa de algo mais complicado para suporte multilib, é claro).

Coisas a serem observadas:

  • Isso não está devidamente documentado em nenhum lugar, mas parece que, ao contrário dos arquivos de especificações , a opção --with-specs configure se aplica aos argumentos da linha de comando passados ao próprio GCC. Assim, você não pode tentar modificar a string *link spec.
  • A sequência %x não altera a linha de comando do GCC, mas acumula argumentos para transmitir ao vinculador. É por isso que eu passo -rpath e -enable-new-dtags diretamente em vez de -Wl .
  • Há várias sugestões on-line sobre quais especificações devem ser transmitidas. Eu não vi este aqui em qualquer lugar, então ele leva um grão de sal. O motivo pelo qual usei o meu próprio é que todos os outros modificam uma cadeia de especificação como *link , o que você não pode fazer com --with-specs , ou adicionam opções à linha de comando do GCC usando -Wl , o que eu tenho certeza alguém disse que eles tinham problemas porque em alguns casos isso confundia o GCC quando eles não estavam ligando. YMMV.
  • Se você usar bootstrapping (o que geralmente é feito a menos que você construa um compilador cruzado, caso em que posso estar errado, mas não acho que esse truque específico de rpath seja útil), isso adicionará um RUNPATH ao Programas do GCC e bibliotecas compartilhadas também. Essa parece ser a opção correta, porque eles foram compilados em relação às bibliotecas que agora estão em $prefix/lib64 , mas vale a pena notar.
  • Eu adicionei -enable-new-dtags , o que coloca isso em DT_RUNPATH em vez de DT_RPATH . Este é o atributo mais recente que toda a documentação diz ser o preferido, < sarcasm > e é por isso que é necessário um sinalizador extra que não seja claramente cruzado nos documentos < / sarcasm & gt ;. Entre as diferenças entre RPATH e RUNPATH estão:

    • Se RUNPATH estiver presente, o RPATH será completamente ignorado.
    • O RPATH substitui LD_LIBRARY_PATH ; o RUNPATH não.
    • Eles trabalham de maneira um pouco diferente para dependências de dependências ( RUNPATH é procurado apenas por dependências diretas; RPATH é procurado por dependências indiretas contanto que nada na cadeia de dependência tenha RUNPATH ). Mais detalhes estão disponíveis aqui .
    • Acho que é tudo, mas não ficaria surpreso se estivesse faltando alguma coisa.

    Como o artigo que eu fiz o link acima indica, nem todo mundo prefere o RUNPATH ao RPATH, mas aqui ele não deve ser um problema a menos que você misture código de compiladores diferentes que requerem diferentes bibliotecas de suporte ao compilador de forma complicada, e se você fizer isso eu não pense que exista uma solução única para todos.

por Daniel H 20.12.2017 / 18:58
fonte