3. Instalação e configuração do GCC

3.1. Versões do GCC

Você pode verificar qual versão do GCC você está rodando ao digitar gcc -v no prompt do shell. Esta também é uma meneira razoavelmente confiável de verificar se você está configurado para ELF ou a.out. No meu sistema ele faz

    $ gcc -v
    Reading specs from /usr/lib/gcc-lib/i486-box-linux/2.7.2/specs
    gcc version 2.7.2

As coisas principais a notar aqui são

• i486. Isto indica que o gcc que você está usando foi construído para um processador 486 --- ao invés disso você pode ter um 386 ou 586. Todos estes processadores podem executar código compilado para cada um dos outros; a diferença é que o código para o 486 tem "enchimento" adicionado em alguns lugares, de modo que executa mais rápido em um 486. Isto não tem qualquer efeito negativo no desempenho de um 386, mas torna os binários ligeiramente maiores.

• box. Isto não tem qualquer importância, e pode dizer algo mais (tal como slackware ou debian) ou nada demais (de forma que o nome completo do diretório é i486-linux). Se você construiu o seu próprio gcc, você pode definir isso em tempo de construção para efeitos cosméticos. Exatamente como eu fiz :-)

• linux. Isto pode dizer, ao invés disso, linuxelf ou linuxaout, e, estranhamente, o significado de cada um varia de acordo com a versão que você está usando.

  
  
  

  • linux significa ELF se a versão é 2.7.0 ou mais nova e a.out nos outros casos.

  • linuxaout significa a.out. Ele foi introduzido como um alvo quando a definição do linux foi alterada de a.out para ELF, de modo que você não verá qualquer gcc do tipo linuxaout mais velho que 2.7.0.

  • linuxelf está obsoleto. Ele é, geralmente, uma versão do gcc 2.6.3 configurada para produzir executáveis ELF. Note que o gcc 2.6.3 possui bugs conhecidos quando produzindo código para ELF --- um upgrade é recomendável.

• 2.7.2 é o número da versão.

Então, em resumo, eu tenho um gcc 2.7.2 produzindo código ELF. Que surpresa.

3.2. Onde ele foi?

Se você instalou o gcc sem assistir, ou se você recebeu-o como parte de uma distribuição, você pode querer descobrir onde ele reside no sistema de arquivos. Os pontos chaves são

• /usr/lib/gcc-lib/alvo/versão/ (e subdiretórios) é onde fica a maior parte do compilador. Isto inclui os programas executáveis que efetuam a compilação propriamente dita, e algumas bibliotecas para versões específicas e arquivos para inclusão.

• /usr/bin/gcc é o driver do compilador --- o componente que você pode realmente executar a partir da linha de comando. Isto pode ser usado com múltiplas versões do gcc, desde que você tenha múltiplos diretórios de compilador (como acima) instalados. Para encontrar a versão padrão que ele vai usar, digite gcc -v. Para forçá-lo a usar outra versão, digite gcc -V versão. Por exemplo

  # gcc -v Reading specs from /usr/lib/gcc-lib/i486-box-linux/2.7.2/specs gcc version 2.7.2 # gcc -V 2.6.3 -v Reading specs from /usr/lib/gcc-lib/i486-box-linux/2.6.3/specs gcc driver version 2.7.2 executing gcc version 2.6.3

  
  
  

• /usr/alvo/(bin|lib|include)/. Se você tem múltiplos alvos instalados (por exemplo, a.out e elf, ou algum tipo de compilador cruzado, as bibliotecas, binutils (as, ld e assim por diante) e arquivos de cabeçalho para o(s) alvo(s) não-nativo(s) podem ser encontrados aqui. Mesmo que você tenha apenas um tipo de gcc instalado você pode descobrir que varios componentes dele são mantidos aqui. Se não, eles estão em /usr/(bin|lib|include).

• /lib/,/usr/lib e outros são diretórios de biblioteca para o sistema nativo. Você também irá precisar de /lib/cpp para muitas aplicações (X faz um uso pesado dele) --- copie-o de /usr/lib/gcc-lib/alvo/versão/ ou faça um link simbólico apontando para lá.

3.3. Onde estão os arquivos de cabeçalho?

Diferente de qualquer coisa que você instalou por si mesmo sob /usr/local/include, existem três fontes principais de arquivos de cabeçalho no Linux:

• A maior parte de /usr/include/ e seus subdiretórios são fornecidos com o pacote binário da libc feito por H. J. Lu. Eu digo `a maior parte' porque você também pode ter arquivos vindos de outras fontes (bibliotecas curses and dbm, por exemplo) aqui, especialmente se você está usando a distribuição mais recente da libc (a qual não vem com curses ou dbm, ao contrário das mais antigas).

• /usr/include/linux e /usr/include/asm (para os arquivos <linux/*.h> e <asm/*.h>) devem ser ligações simbólicas para os diretórios linux/include/linux e linux/include/asm na distribuição do fonte do kernel. Você precisa instalá-los se planeja fazer qualquer desenvolvimento não-trivial; eles não estão lá apenas para compilar o kernel. Você pode descobrir, também, que precisa executar make config no diretório do kernel depois de extrair os fontes. Muitos arquivos dependem de <linux/autoconf.h> o qual, por outro lado, pode não existir, e em algumas versões do kernel asm é um link simbólico e criado apenas durante a execução de make config. Então, se você extrair os seus fontes do kernel sob /usr/src/linux, faça

  $ cd /usr/src/linux $ su # make config [responda as questões. A menos que você planeje ir em frente e compilar o kernel não importa _muito_ o que você disser] # cd /usr/include # ln -s ../src/linux/include/linux . # ln -s ../src/linux/include/asm .

  
  
  

• Arquivos tais como <float.h>, <limits.h>, <varargs.h>, <stdarg.h> e <stddef.h> variam de acordo com a versão do compilador, de forma que são encontrados em /usr/lib/gcc-lib/i486-box-linux/2.7.2/include/ e lugares semelhantes.

3.4. Construindo compiladores cruzados