Re: [gentoo-user-br] PROBLEMAS DEPOIS DE UM EMERGE -EVT

[Thiago Nunes]

Em 17/10/07, Daniel Medeiros<m3g1st@×××××.com> escreveu:

> Pessoal, to precisando de uma ajuda aqui. Uso linux e computador ha um ano e
> dois meses e um mes de Gentoo.

Usa "computador" e "linux" a um ano e pouco? Então já começou usando
linux? (Algo realmente incomum)

> Eu reinstalei o sistema sem a biblioteca TLS, para instalar a XEN, e agora
> estou tendo um problema para recompilar o kernel.

Perai, reinstalou o sistema só pra tirar o tls? Esse tipo de
procedimento não tem cabimento no gentoo justamente porque o portage é
muito eficiente no gerenciamento dos pacotes. Se você queria tirar o
tls do sistema bastava fazer "emerge --unmerge tls && emerge --deep
--update --newuse world && emerge --depclean && revdep-rebuild". Se o
tls não fosse dependência de nada esses procedimentos removeriam
qualqure vestigio dela do sistema.

Além disso eu não entendi o que o tls tem a ver com o xen.

A propósito, o kernel que está dando problema é o do xen?

> Dei suporte pro
> -fomit-frame-pointer na glibc que não tava compilando. beleza, com isso o
> sistema parou de travar e de eu ter que dar revdep com cd de recuperação,
> mas continuo sem conseguir recompilar o kernel que dá um impossível de
> remover no driver "crypto" (?), e meu iptables_nat não sobe mais.

A glibc não tava compilando sem -fomit-frame-pointer? Mas tu ta usando
-O3... Dá uma olhada no man do gcc: "Enabled at levels -O, -O2, -O3,
-Os.". E além disso não tem algo precisar de um parâmetro de
otimização pra poder ser compilado.

Além disso tu disse que o sistema tava travando. Tudo bem, mas o
revdep-rebuild não é o tipo de ferramenta que resolve problemas de
travamento.

Você poderia explicar melhor o "impossível de remover no driver \"crypto\""?

E o que é o iptables_nat que você diz? O módulo pro kernel?

> Abaixo vai meu make.conf. Inclusive se houver alguma sugestão de melhoria,
> ou alguma bobagem que coloquei agradeceria sugestões.
>
> CXXFLAGS="${CFLAGS}"

Primeiramente. O emerge quando carrega o make.conf para o ambiente
dele vai inserindo as variáveis definidas no make.conf linearmente, ou
seja, no seu caso ele carrega o CXXFLAGS antes de carregar o CFLAGS.
Eu não sei se você sabe, mas toda vez que você chama uma variável com
um $ na frente você está dizendo ao shell para substituir o nome da
variável pelo valor dela. Então, observe, quando você define a
variável CXXFLAGS você invoca o valor da variável CFLAGS, mas a
variável CFLAGS ainda não existe, então o valor da sua variável
CXXFLAGS fica vazio, ou seja, todos os seus programas que usam C++
estão sendo compilados sem nenhum parâmetro de otimização.

> CFLAGS="-march=athlon -pipe -O3 -fomit-frame-pointer -funroll-all-loops
> -mno-tls-direct-seg-refs"

Hm... Você disse que usa computador a um ano e pouco. Mas esse seu
computador foi comprado novo a um ano e pouco? Se sim ele não pode ser
um Athlon comum como você colocou no seu march, deve ser um Sempron ou
Athlon 64. Athlon comum é o meu que eu tenho em casa, um
athlon-thunderbird de 1ghz que eu comprei no início de 2003.

Vocês está usando o nível de otimização 3, o que não é recomendado a
partir do gcc4, quando as otimizações ficaram mais agressivas e
instáveis. Muitas vezes as otimizações agressivas podem ser um tiro
pela culatra, pois bibliotecas otimizadas agressivamente podem ficar
instáveis e prejudicar programas que usam elas e dando mais dor de
cabeça do que se o problema fosse simplesmente com o programa em
questão. Além disso otimizações geralmente aumentam o tamanho do
código, fazendo com que ocupem mais memória, o que geralmente é ruim.

Bom... o "-funroll-all-loops" é o parâmetro mais abominável que você
poderia ter escolhido pois desenrolando todos os loops o tamanho de
alguns binários aumenta absurdamente, consequentemente o uso de
memória também. E veja bem, enquanto você economiza alguns
milisegundos com loops desenrolados você faz o kernel gastar alguns
milisegundos a mais tendo que gerenciar bem mais memória alocada.
Enquanto isso você poderia ter as mesmas funcionalidades com bem mais
memória livre, então, não vale a pena.

E você poderia explicar o porque do "-mno-tls-direct-seg-refs"?

> CHOST="i686-pc-linux-gnu"
> MAKEOPTS="-j3"
> AUTOCLEAN="yes"

O AUTOCLEAN="yes" é automático, não precisa definir.

> FEATURES="${FEATURES} -userfetch buildpkg ccache"

A variável FEATURES não precisa ser definida recursivamente, o portage
ja faz isso automaticamente.

> FETCHCOMMAND="/usr/bin/getdelta.sh \${URI}"
> LINGUAS="pt_BR en"

O "en" também é automático, não preisa definir.

> CCACHE_SIZE="3G"
> VIDEO_CARDS="nvidia via dummy v4l vesa"
>
> USE="-qt -scanner -kerberos -ipv6 -oss -apm -kde -xmms -gpm -gnome \
>      -oracle -oracle7 -apm -pcmcia -plotutils -ladspa -esd -evo -eds \
>      -arts -emboss -smartcard nls x86 avi berkdb bitmap-fonts jikes \
>      crypt cups encode fortran f77 gdbm gif imlib jpeg libg++ \
>      libwww mad mikmod motif mpeg ncurses nls oggvorbis opengl pam \
>      pdflib png python readline sdl spell ssl svga tcpd truetype X \
>      xml2 xv zlib alsa apache2 vim-syntax php bash-completion acpi \
>      dns bzip2 cddb cairo directfb fbcon ftp gd mime minimal mp3 \
>      mplayer pdf sox tetex usb xvid cdr cdparanoia dri foomaticdb \
>      gstreamer v41 fam aalib cscope -javascript -gtk -qt3 -qt4 \
>      symlink -java lua mozilla dga firefox imagemagick imap -krb4 \
>      libcaca lm_sensors sockets svg v4l win32codecs xulrunner xvmc zoran \
>      vidix v4l2 aac openal hal dvd dvdr dvdread dv dvb flac \
>      videos vhosts ggi a52 offensive -debug -bindist musepack quicktime \
>       -doc mmx 3dnow"

Acho que essa USE v41 não existe, só v4l. Além disso não é necessário
usar a "\" pra indicar quebra de linha quando se abre uma áspa,
enquanto as áspas não forem fechadas o shell continua colocando tudo
que vem pra dentro da variável, mesmo que ele encontre uma quebra de
linha.

> GENTOO_MIRRORS="ftp://ftp.las.ic.unicamp.br/pub/gentoo/ "
> SYNC="rsync://rsync.samerica.gentoo.org/gentoo-portage"
>
> CONFIG_PROTECT=-/etc/conf.d/hdparm
>
>
> obs. to adorando o Gentoo. Dei bobeira de não usar antes...

Por enquanto era isso.

Até.
-- 
gentoo-user-br@g.o mailing list