Ubuntu 12 quebra o gcc 4.7 construído a partir da fonte

Question

Eu uso o C ++ 11 extensivamente, então logo após instalar o novo Xubuntu 12.04 LTS, eu fui construir o gcc a partir do código-fonte. Depois de obter as dependências necessárias usando sudo apt-get build-dep gcc-4.7-base , eu verifiquei a tag 4.7.0 do gcc no Subversion e comecei a criá-la.

No meu laptop de 64 bits, a compilação (configurada com --disable-multilib --enable-libstdcxx-time=rt --enable-languages=c,c++ ) não encontrou arquivos relacionados à libc6-dev, apesar de o pacote estar sendo instalado. Eu só fui capaz de corrigir os problemas ligando soft / usr / lib64 para / usr / lib / x86_64-linux-gnu por sugestão de uma postagem do StackOverflow. Depois disso, o gcc foi construído com sucesso e parece funcionar bem após a instalação.

Meu sistema de desktop de 32 bits foi outra história. Eu tive o mesmo problema inicial em que os arquivos libc6-dev não puderam ser encontrados pela cadeia de construção do gcc. No final, tive que exportar as seguintes variáveis de ambiente para que ele fosse compilado corretamente (a idéia foi tirada de aqui ):

export LIBRARY_PATH=/usr/lib/i386-linux-gnu/
export C_INCLUDE_PATH=/usr/include/i386-linux-gnu
export CPLUS_INCLUDE_PATH=/usr/include/i386-linux-gnu

Esperando que tenha resolvido meus problemas, fui testar o build do gcc recém-instalado, ponto no qual ele falhou instantaneamente no primeiro projeto em que o testei (construindo a última versão do vim a partir do código-fonte). Ele não encontrou os mesmos arquivos que a compilação do gcc não encontrou e emitiu a seguinte mensagem antes de falhar em uma enxurrada de erros:

  

Hmm, sed é muito pessimista em relação aos arquivos de cabeçalho do seu sistema. Mas   não despejou núcleo - estranho! Vamos continuar com cuidado ... Se isso   falhar, você pode querer remover linhas ofensivas de osdef.h ou tentar   com um arquivo vazio osdef.h, se o seu compilador pode fazer sem função   declarações.

Quando levei essa história para o canal de IRC do gcc, várias pessoas de lá expressaram frustração com o Ubuntu e me disseram que esses erros foram causados pelo Ubuntu 12 mudando os caminhos de longa data para os arquivos.

Alguém poderia lançar alguma luz sobre isso?

    

Answer 1

Como eu disse no meu comentário, o problema não é um bug no GCC ou no Ubuntu, mas sim um recurso incompatível: multiarch . O objetivo do multiarch é permitir que binários para várias arquiteturas sejam instalados no mesmo sistema de arquivos ao mesmo tempo sem colisões. Isso substituirá o antigo sistema de bibliotecas de 32 bits vs. 64 bits que existia, mas é realmente mais importante onde queremos ter o Intel e o ARM instalados de uma só vez, por exemplo. Presumivelmente, isso não é muito interessante para computadores de mesa, mas o Ubuntu existe em muitos dispositivos incorporados (ou serve) que podem fazer esse tipo de coisa.

Fazer alterações como essa naturalmente resulta na movimentação de arquivos, portanto, podemos esperar algumas interrupções durante o período de transição. Atualmente, o GCC não oferece suporte aos novos locais, mas acabará fazendo isso.

A partir de uma instalação padrão na área de trabalho, essas etapas de configuração permitiram que a compilação funcionasse para mim:

amd64 (testei este aqui):

sudo -i
# apt-get install libppl0.11-dev libmpfr-dev libgmp-dev libc6-dev-i386
# cd /usr/include
# ln -s x86_64-linux-gnu/* .
# cd /usr/lib
# ln -s x86_64-linux-gnu/crt* .

Eu vejo que você está usando o Ubuntu de 32 bits. Eu não testei isso, mas fiz as mudanças óbvias.

ix86:

sudo -i
# apt-get install libppl0.11-dev libmpfr-dev libgmp-dev libc6-dev
# cd /usr/include
# ln -s i386-linux-gnu/* .
# cd /usr/lib
# ln -s i386-linux-gnu/crt* .

AVISO: a inserção dos links não é, em geral, inofensiva, para a maioria das pessoas, mas pode causar problemas futuros. (Principalmente apenas se você deseja criar projetos de 64 e 32 bits na mesma máquina.)