Blog do Yporti

Tenho visto que muitos usuários do Gentoo não sabem lidar com os erros de compilação, tendo problemas inclusive para conseguir ajuda, uma vez que fornecem poucas informações, como logs incompletos. Justamente por isso escrevi este post, para dar uma ideia de como eu costumo lidar com estes problemas no meu sistema.

Para demonstrar a minha rotina ao encontrar problemas de compilação, usarei o exemplo abaixo, um erro ao compilar o pacote sys-libs/zlib. Abaixo está o log inútil que citei no início do artigo, contendo apenas a parte final:

* ERROR: sys-libs/zlib-1.2.5-r2 failed (compile phase):
* (no error message)
* Call stack:
* ebuild.sh, line 56: Called src_compile
* environment, line 2193: Called die
* The specific snippet of code:
* emake || die
* If you need support, post the output of 'emerge --info =sys-libs/zlib-1.2.5-r2',
* the complete build log and the output of 'emerge -pqv =sys-libs/zlib-1.2.5-r2'.
* The complete build log is located at '/var/tmp/portage/sys-libs/zlib-1.2.5-r2/temp/build.log'.
* The ebuild environment file is located at '/var/tmp/portage/sys-libs/zlib-1.2.5-r2/temp/environment'.
* S: '/var/tmp/portage/sys-libs/zlib-1.2.5-r2/work/zlib-1.2.5
>>> Failed to emerge sys-libs/zlib-1.2.5-r2, Log file:
>>> '/var/tmp/portage/sys-libs/zlib-1.2.5-r2/temp/build.log'

Veja, com isso podemos saber apenas que o problema foi com o pacote sys-libs/zlib e durante a fase de compilação (src_compile). Apesar da própria mensagem citar o local do log completo, os usuários ignoram isso. Agora veja o que acontece se pegarmos o log com algumas linhas a mais:

cc -O2 -march=native -fgraphite-identity -ftree-vectorize -pipe -DNO_FSEEKO -DNO_snprintf
-DHAS_sprintf_void -c -o example.o example.c
cc -O2 -march=native -fgraphite-identity -ftree-vectorize -pipe -DNO_FSEEKO -DNO_snprintf
-DHAS_sprintf_void -c -o adler32.o adler32.c
example.c:1:0: sorry, unimplemented: Graphite loop optimizations cannot be used (-fgraphite,
-fgraphite-identity, -floop-block, -floop-flatten, -floop-interchange, -floop-strip-mine,
-floop-parallelize-all, and -ftree-loop-linear)
adler32.c:1:0: sorry, unimplemented: Graphite loop optimizations cannot be used (-fgraphite,
-fgraphite-identity, -floop-block, -floop-flatten, -floop-interchange, -floop-strip-mine,
-floop-parallelize-all, and -ftree-loop-linear)
make: *** [adler32.o] Error 1
make: *** Waiting for unfinished jobs....
make: *** [example.o] Error 1
emake failed
* ERROR: sys-libs/zlib-1.2.5-r2 failed (compile phase):
* (no error message)
* Call stack:
* ebuild.sh, line 56: Called src_compile
* environment, line 2193: Called die
* The specific snippet of code:
* emake || die
* If you need support, post the output of 'emerge --info =sys-libs/zlib-1.2.5-r2',
* the complete build log and the output of 'emerge -pqv =sys-libs/zlib-1.2.5-r2'.
* The complete build log is located at '/var/tmp/portage/sys-libs/zlib-1.2.5-r2/temp/build.log'.
* The ebuild environment file is located at '/var/tmp/portage/sys-libs/zlib-1.2.5-r2/temp/environment'.
* S: '/var/tmp/portage/sys-libs/zlib-1.2.5-r2/work/zlib-1.2.5'
>>> Failed to emerge sys-libs/zlib-1.2.5-r2, Log file:
>>> '/var/tmp/portage/sys-libs/zlib-1.2.5-r2/temp/build.log'

Opa, agora é diferente, sabemos onde e qual foi o problema. Podemos ver erro ao compilar example.c e adler32.c, isso ocorre porque usei -j2, se usasse -j1 ele provavelmente pararia no primeiro erro. Agora vamos isolar a mensagem de erro (o nome do arquivo não é importante):

sorry, unimplemented: Graphite loop optimizations cannot be used (-fgraphite, -fgraphite-identity,
-floop-block, -floop-flatten, -floop-interchange, -floop-strip-mine, -floop-parallelize-all, and
-ftree-loop-linear)

Isso nos dá uma ideia do que houve, eu usei uma flag do Graphite no make.conf e aparentemente não está funcionando. Neste ponto recorremos ao Google! Os primeiros resultados mostram duas causas para isso: atualização do ppl incorreta ou simplesmente ter compilado o GCC sem a flag graphite, portanto, sem suporte a esta CFLAG (foi este o caso).

Existem alguns pontos importantes que gostaria de destacar, o primeiro deles é o número de compilações em paralelo (-j), quanto maior esse número, mais difícil pode ser achar a parte do erro, uma vez que o problema pode ocorrer em apenas um dos arquivos sendo compilados.

O idioma do sistema também pode dificultar, uma vez que certas mensagens são traduzidas e quando você for procurar informações sobre o erro, terá chances bem menores de sucesso. Exatamente por isso prefiro usar todos meus sistemas em en_US, por isso e pela estética de menus, que ficam horríveis com algumas traduções. ;)

Basicamente esta é a rotina para solução de problemas por conta própria, depois de fazer isso e não ter sucesso, você pode recorrer às listas de discussão, canais no IRC e fóruns. Se ainda sim não conseguir resolver, é preciso ver se já não existe um bug reportado para este pacote em https://bugs.gentoo.org/ (isso pode/deve ser feito na fase inicial também), muitas vezes já possuem até patch de correção, mas caso você seja o primeiro a encontrar o problema, reporte o bug conforme as orientações do site, fornecendo o log completo e informações sobre o sistema (emerge --info, no mínimo) e sobre como o bug ocorreu.

Espero que o artigo venha a ser útil para usuários que estão começando e ainda se sentem perdidos quando se deparam com problemas. Até a próxima!

Uso Gentoo Linux há quase 3 anos e nesse período fiz centenas de instalações (literalmente), usei várias combinações de CFLAGS e compiladores e hoje posso dizer que a opção mais adequada é se manter conservador e usar as tais safe flags.

Ultimamente tinha muitos bugs com o Xorg e KDE, praticamente todos desapareceram quando resolvi desativar as flags experimentais do Graphite (mesmo utilizando ~amd64). O ruim de definir esse tipo de flags globalmente é que fica muito difícil debugar e achar a origem do erro, o problema pode estar em um biblioteca de pouco importância em relação aos pacotes com problema. Portanto, minha recomendação atual para usuários do Gentoo é ficar com as safe flags e deixar as CFLAGS mais agressivas e experimentais para pacotes específicos, o que pode ser feito facilmente com o Portage.

Por exemplo, para definir CFLAGS específicas para o pacote app-arch/bzip2 eu posso usar:

# mkdir -p /etc/portage/env/app-arch
# echo 'CFLAGS="-O3 -march=native -pipe"' > /etc/portage/env/app-arch/bzip2

Com isso, o pacote app-arch/bzip2 sempre usará as CFLAGS especificadas no arquivo, ignorando a configuração global do make.conf. O método pode ser usado para outras variáveis específicas dos ebuilds, mas isso está além do objetivo deste post.

Espero que a dica sirva para alertar usuários que precisam de um sistema mais confiável e que ainda sim possa testar as novidades do GCC em pacotes específicos. Até a próxima! :~)

O comportamento padrão do GCC pode ser alterado via Specs, que são arquivos contendo as instruções sobre quais flags usar e em que circunstâncias. Você pode olhar a spec padrão do seu GCC com o comando:

# gcc -dumpspecs

Após ler o artigo sobre --as-needed do Gentoo percebi que poderia usar isso para forçar o uso de minhas LDFLAGS, umas vez que alguns pacotes não respeitam aquelas definidas no make.conf. O procedimento é bastante simples:

# export SPECSFILE=$(dirname "$(gcc -print-libgcc-file-name)")/ldflags.specs
# export CURRPROFILE=/etc/env.d/gcc/$(gcc-config -c)
# gcc -dumpspecs | sed -e '/link:/,+1 s:--eh-frame-hdr:\0 *SUASFLAGS*:' > "$SPECSFILE"
# sed "${CURRPROFILE}" -e '1i\GCC_SPECS='$SPECSFILE > "${CURRPROFILE}-ldflags"
# gcc-config "$(basename "${CURRPROFILE}")-ldflags"
# source /etc/profile

No caso, basta substituir o SUASFLAGS pelas suas LDFLAGS, no meu caso (que uso -O1 --as-needed --hash-style=gnu --sort-common) ficaria assim:

# gcc -dumpspecs | sed -e '/link:/,+1 s:--eh-frame-hdr:\0 -O1 --as-needed --hash-style=gnu --sort-common:' > "$SPECSFILE"

Esta dica deve ser usada apenas por usuários avançados e que sabem o que estão fazendo. Como visto no passos acima, basta usar o gcc-config para alternar entre os diferentes specs ou mesmo o GCC vanilla.