AMD64... x86_64... libs 32... [RESOLVIDO]

1. AMD64... x86_64... libs 32... [RESOLVIDO]

kinokrek
(usa Sabayon)

Enviado em 01/10/2010 - 15:20h

Olha, eu estou com uma teoria sobre alguns problemas que venho enfrentando (http://www.vivaolinux.com.br/comunidades/formPost.php?codigo=555&codtopico=62470) e que formulei baseando-me em outros a que se somaram e gostaria de orientação de alguém experiente para saber se faz sentido (sou iniciante tanto em linux como em gentoo/sabayon).

Os problemas que se somaram foram notados quando instalei o skype, primeiramente, via portage, e como apresentou os problemas, também através do entropy, o que não os resolveu. O que acontece quando tento rodar o skype:

krek@scarecrow ~ $ skype
./skype: /lib32/libc.so.6: version `GLIBC_2.11' not found (required by /usr/lib32/libpng14.so.14)
./skype: /lib32/libc.so.6: version `GLIBC_2.11' not found (required by /usr/lib32/libfreetype.so.6)
./skype: /lib32/libc.so.6: version `GLIBC_2.11' not found (required by /usr/lib32/libICE.so.6)

Só ressaltando: isso aconteceu tanto através do portage quanto do entropy.

Pesquisando sobre esses erros, acabei encontrando referências sobre programas que ainda não têm fontes para arquitetura 64bits e pessoas que se utilizam do chroot para emergir e utilizar programas 32bits.

http://groups.google.com/group/funtoo-dev/browse_thread/thread/7148673d1ed1e105

O que me levou a procurar instruções de como fazê-lo:

http://www.gentoo.org/proj/en/base/amd64/howtos/index.xml?part=1&chap=2

Abortei a tentativa quando, logo de início me deparei com o seguinte na tal URL:

$ wget -c ftp://distfiles.gentoo.org/releases/x86/2006.1/stages/stage3-i686-2006.1.tar.bz2

Note: Note that we dowload a stage for x86, not for AMD64.

Primeiro: a data do pacote, 2006.1, me deixou receoso; e então, um repentino insight...

A versão do Sabayon que instalei inicialmente em meu notebook foi a partir desta imagem:
http://na.mirror.garr.it/mirrors/sabayonlinux/iso/Sabayon_Linux_5.3_amd64_K.iso

Um 5.3 para amd64... Fiz isso pois vi em muitas mensagens que a tal arquitetura era a recomendada para Intel 64bits.

Todos os problemas surgiram depois de atualizações recentes... Ontem, fiz mais uma atualização recomendada.

Enfim, acabei desistindo de tentar o Skype instalado e me preparava para testar sua utilização através do wine. Quando, ao resolver checar como estavam os dispositivos de placa de som e tal no Wine, eis que surge o mesmícemo problema:

$ winecfg
Wine cannot find the FreeType font library. To enable Wine to
use TrueType fonts please install a version of FreeType greater than
or equal to 2.0.5.
http://www.freetype.org
err:module:load_builtin_dll failed to load .so lib for builtin L"winex11.drv": /lib32/libc.so.6: version `GLIBC_2.11' not found (required by /usr/lib32/libICE.so.6)
err:module:load_builtin_dll failed to load .so lib for builtin L"winex11.drv": /lib32/libc.so.6: version `GLIBC_2.11' not found (required by /usr/lib32/libICE.so.6)
Application tried to create a window, but no driver could be loaded.

Sempre o GLIBC_2.11 ...

Acontece que ontem mesmo eu estava utilizando o wine sem qualquer problema desse.

Voltando à questão do AMD64... Vi o que o uname -a me indicou:

$ uname -a
Linux scarecrow 2.6.34-sabayon #1 SMP Mon Sep 20 20:58:36 UTC 2010 x86_64 Intel(R) Core(TM) i5 CPU M 450 @ 2.40GHz GenuineIntel GNU/Linux

x86_64??? E o AMD64???

O que queria saber é se tudo isso está correto mesmo e se a minha estranheza não é por pura leiguice. Acho que essas atualizações recentes instalaram a arquitetura x86_64 sobre a AMD64 e isso não deu muito certo, pois, após cada atualização, estou enfrentando novos problemas com as "lib32". Porque é fato: Kdenlive (MLT) e Wine já foram instalados e rodaram limpeza anteriormente, há um mês ou mês e meio.

Será que tudo se resolveria se eu baixasse a imagem do x86_64 e instalasse tudo do zero?

Por favor, alguém me oriente se isso faz sentido, preciso de explicações porque a cada dia está mais insustentável a utilização desse sistema, com o qual me surpreendi inicialmente, para mim.

Abraços.

0 0

Quote

2. MELHOR RESPOSTA

albfneto
(usa openSUSE)

Enviado em 01/10/2010 - 18:46h

olha, pacote x86_64,funciona em amd64...
o skype usa libc 32,mas, no sabayon e no gentoo, tem as duas libcs, já por default o sabayon e o gentoo, deveriam instalar automatico a que o sistema precisa.

mas o que estou estranhando é que tem GLIBC 2.11 no portage, no overlay loongson.
no entropy acho qua ainda não ,mas no portage tem.
eu instalei OUTRO DIA,para rodar o BOINC novo!

veja meu post abaixo:
tá em Italiano, pq é uma comunidade italiana de Sabayon, mas os comandos são os mesmos

http://sabayon-mania.com/forum/boinc/problema-boinc/

ldconfignão vai funcionar se vc não estiver com a versão 2.11 de GLIBC instalada.

faça o seguinte.... atualize entropy e portage, senão o fez antes e depois procure por Glibc 2.11,eveja aglibc que está instalada,com os comandos:

# equo update
# emerge --sync
$ equo search glibc
$ emerge -s glibc

supondo que ache, instale com portage normal, supondo que não ache a 2.11 ou mais nova (as antigas não servem)

adicione o overlay loongson, atualize o verlay e instale com os comandos:

# layman -a loongson
# layman -s loongson
# equo install autounmask
# autounmask sys-libs/glibc-2.11.2
# LINGUAS="pt_BR" USE="nls" emerge --pretend --nodeps =sys-libs/glibc-2.11.2
# LINGUAS="pt_BR" USE="nls" emerge --verbose --nodeps =sys-libs/glibc-2.11.2
# layman -d loongson
# equo rescue spmsync

NOTA "nls" é Native language support, opcional. as opções nodeps, é
para não fazer downgrade de binutils para uma versão muito antiga (para verificar isso; $ emerge -p =sys-libs/glibc-2.11.2)

o linguas em pt br, é pq Glibc é biblioteca multilingue de GNOME em C, e é para não instalar USE FLAGS para russo,dinamarquês, punjabi etc....srrsrsrsrsrs

depois disso,acho que o skype instalado vai funcionar,
se ainda não instalou, instale,já em pt-br;

# LINGUAS="pt_BR" emerge -av skype OU
# equo install skype

seu sistema continua sem instalar nada que use gtk+?

agora me lembrei duma coisa,vc removeu,no seu outro post a linha:

ACCEPT_KEYWORDS="~amd64"

em /etc/make.conf, não? recolocou?, pq se não recolocou, tá baixando arquitetura dual, pacote só 32,64 compatível,multiarquitetura.

0 0

Quote

3. Re: AMD64... x86_64... libs 32... [RESOLVIDO]

/bin/laden
(usa Void Linux)

Enviado em 01/10/2010 - 15:45h

Cara 'x86_64' é a forma genérica para representar processadores com instruções 64 bit, não importando se eles são AMD ou Intel (exceto para família Intel-Itanium). Logo essa sua "teoria" de que "... as atualizações recentes instalaram a arquitetura x86_64 sobre a AMD64" é pura viagem, afinal amd64 e x86_64 são a mesma arquitetura.

0 0

Quote

4. Re: AMD64... x86_64... libs 32... [RESOLVIDO]

kinokrek
(usa Sabayon)

Enviado em 01/10/2010 - 17:55h

Hehehe. Valeu!
Perdendo mais do meu precioso tempo, eu havia me dado conta disso...

Estou tentando aqui resolver...

Tentei #ldconfig -v e nada. O que poderia fazer?

0 0

Quote

5. Re: AMD64... x86_64... libs 32... [RESOLVIDO]

kinokrek
(usa Sabayon)

Enviado em 01/10/2010 - 21:41h

Opa! Acho que vai dar certo o lance do GLIBC agora... Está emergindo.
Eu estava muito intrigado com a versão que pedia, porque eu não a via disponível pelo $ emerge -s glibc.
O que me intriga é por que o wine de uma hora para outra requisitou essa versão nova do GLIBC (assim como o fez o Skype)?
Acho que ele não tinha sido atualizado, porque foi atualizado pelo "equo update" numa atualização que fiz meia hora atrás.
Embora não tenha a familiaridade necessária para estranhar essas coisas, não é estranho tal coisa? Ainda mais com um pacote cuja versão mais nova nem aparece nos repositórios padrões? Nem como dependência...

Queria entender esse repositório loongson. Por que é adicionado e tem que ser removido depois da compilação?

Sobre o GTK... Ainda nada. Vou tentar novamente depois da compilação do GLIB.
Com esse novo problema, vi que eu não tinha feito um ldconfig antes.
Quando terminar, vou tentar. Se não der, vou tentar reinstalar o gtk, já que vi que o entropy fez atualizações agora há pouco no atk e cairo (duas das três, a terceira era o pango, dependências que, apesar de instaladas, impediam uma reinstalação do gtk).

É verdade que tinha feito essa mudança (retirar o ~amd64), mas havia a desfeito e tentado e não consegui.
Só para constar, o início do /etc/make.conf está assim:

# These settings were set by the catalyst build script that automatically built this stage
# Please consult /etc/make.conf.example for a more detailed example

CFLAGS="-march=native -O2 -pipe"
CHOST="x86_64-pc-linux-gnu"
CXXFLAGS="${CFLAGS}"
LDFLAGS="-Wl,-O1,--as-needed"
ACCEPT_KEYWORDS="~amd64"
MAKEOPTS="-s -j4"
FEATURES="parallel-fetch collision-protect"
#PORTAGE_NICENESS="8"
LINGUAS="pt_BR"
ACCEPT_LICENSE="*"

Fiz uma alteração no -march após ler algumas documentações do gcc que indicam essa CFLAG para versões posteriores a 4.3. O que você(s) acha(m)? (Meu processador é Intel i5 M 450.)

Aliás, Alberto, estes espelhos brasileiros e sulamericanos (http://www.vivaolinux.com.br/etc/make.conf-3) não funfaram por aqui.

0 0

Quote

6. Re: AMD64... x86_64... libs 32... [RESOLVIDO]

kinokrek
(usa Sabayon)

Enviado em 01/10/2010 - 21:44h

Wine e Skype funfando!!!

O problema do GLIB: resolvido!

Muito obrigado mesmo a todos!

0 0

Quote

7. Re: AMD64... x86_64... libs 32... [RESOLVIDO]

kinokrek
(usa Sabayon)

Enviado em 01/10/2010 - 22:34h

AHHHHHHHHHHHHHHHH!
Cai alho!!!
UHUUUUUUUUUUUUUUUU!
Deu certo!!!

KDENLIVE instalado pelo portage!!!

Enfim... Eis o que aconteceu após a instalação do GLIB como o Alberto indicou acima.

Atualização de arquivos de configuração seguindo a documentação do emerge: # man emerge

Com # ldconfig -v consegui fazer tanto o wine quanto o skype funcionarem.

Então tentei instalar o GTK (# emerge -av gtk+) e ele deu os mesmos erros. Pra efeito de documentar (e para que outros possam encontrar através de mecanismos de busca):

(...)
checking whether x86_64-pc-linux-gnu-gcc and cc understand -c and -o together... yes
checking whether make sets $(MAKE)... (cached) yes
checking for x86_64-pc-linux-gnu-pkg-config... no
checking for pkg-config... /usr/bin/pkg-config
checking pkg-config is at least version 0.9.0... yes
checking for BASE_DEPENDENCIES... configure: error: Package requirements (glib-2.0 >= 2.23.6 atk >= 1.29.2 pango >= 1.20 cairo >= 1.6) were not met:

Package dri2proto was not found in the pkg-config search path.
Perhaps you should add the directory containing `dri2proto.pc'
to the PKG_CONFIG_PATH environment variable
Package 'dri2proto', required by 'gl', not found

Consider adjusting the PKG_CONFIG_PATH environment variable if you
installed software in a non-standard prefix.

Alternatively, you may set the environment variables BASE_DEPENDENCIES_CFLAGS
and BASE_DEPENDENCIES_LIBS to avoid the need to call pkg-config.
See the pkg-config man page for more details.

!!! Please attach the following file when seeking support:
!!! /var/tmp/portage/x11-libs/gtk+-2.20.1-r1/work/gtk+-2.20.1/config.log
* ERROR: x11-libs/gtk+-2.20.1-r1 failed:
* econf failed
*
* Call stack:
* ebuild.sh, line 56: Called src_configure
* environment, line 3134: Called econf '--libdir=/usr/lib64' '--disable-gtk-doc' '--with-libjpeg' '--without-libjasper' '--with-libtiff' '--enable-xinerama' '--enable-cups=auto' '--disable-introspection' '--disable-papi' '--with-libpng' '--with-gdktarget=x11' '--with-xinput'
* ebuild.sh, line 558: Called die
* The specific snippet of code:
* die "econf failed"
*
* If you need support, post the output of 'emerge --info =x11-libs/gtk+-2.20.1-r1',
* the complete build log and the output of 'emerge -pqv =x11-libs/gtk+-2.20.1-r1'.
* The complete build log is located at '/var/tmp/portage/x11-libs/gtk+-2.20.1-r1/temp/build.log'.
* The ebuild environment file is located at '/var/tmp/portage/x11-libs/gtk+-2.20.1-r1/temp/environment'.
* S: '/var/tmp/portage/x11-libs/gtk+-2.20.1-r1/work/gtk+-2.20.1'

>>> Failed to emerge x11-libs/gtk+-2.20.1-r1, Log file:

>>> '/var/tmp/portage/x11-libs/gtk+-2.20.1-r1/temp/build.log'

* Messages for package x11-libs/gtk+-2.20.1-r1:

* ERROR: x11-libs/gtk+-2.20.1-r1 failed:
* econf failed
*
* Call stack:
* ebuild.sh, line 56: Called src_configure
* environment, line 3134: Called econf '--libdir=/usr/lib64' '--disable-gtk-doc' '--with-libjpeg' '--without-libjasper' '--with-libtiff' '--enable-xinerama' '--enable-cups=auto' '--disable-introspection' '--disable-papi' '--with-libpng' '--with-gdktarget=x11' '--with-xinput'
* ebuild.sh, line 558: Called die
* The specific snippet of code:
* die "econf failed"
*
* If you need support, post the output of 'emerge --info =x11-libs/gtk+-2.20.1-r1',
* the complete build log and the output of 'emerge -pqv =x11-libs/gtk+-2.20.1-r1'.
* The complete build log is located at '/var/tmp/portage/x11-libs/gtk+-2.20.1-r1/temp/build.log'.
* The ebuild environment file is located at '/var/tmp/portage/x11-libs/gtk+-2.20.1-r1/temp/environment'.
* S: '/var/tmp/portage/x11-libs/gtk+-2.20.1-r1/work/gtk+-2.20.1'

Enfim... Olhando com mais cuidado, vi que não era dependência de pango glib cairo... que eu já tinha em versões superiores às requisitadas instaladas. Mas esse tal pacote dri2proto requisitado por esse gl.
Emergi: # emerge -av dri2proto
e ele requisitou numa nova tentativa um pacote chamado glproto, o qual também foi emergido.

Após isso, o gtk+ foi instalado com sucesso e o kdenlive/mlt também...

Enfim, fica a lição: ao obter um erro leia com atenção o log e tente entender o erro e tudo melhor.

Uma pena ter demorado tanto tempo para sacar isso... mas valeu. Isso tudo me fez ler documentações diversas, aprender sobre o portage, compilação, useflags, glib, ldconfig, arquiteturas... Sai sabendo mais sobre Gentoo/Sabayon/Linux. E acho que estou com uma configuração mais a ver com meu hardware agora.
Nada mais recompensador do que poder usar seu sistema operacional fluidamente do jeito que queria e na tentativa/erro/aprendizagem. É... Essas coisas me dão prazer.

E, por último, mas não menos importante, claro, everything with a little help from my friends... aaaaaaaaa little help from my friend... uhhhhhhhh...

(Tô me sentindo meio que bêbado e chamando todo mundo de amigo, irmão... Mas quem "ajuda", amigo é!)

Alberto, muito obrigado mesmo. És um guru do Sabayon mesmo.
Bin Laden, obrigado também.

Até a próxima. Resolvido!
Usem Sabayon!

0 0

Quote

8. Re: AMD64... x86_64... libs 32... [RESOLVIDO]

albfneto
(usa openSUSE)

Enviado em 01/10/2010 - 23:30h

respondendo..

sobre os espelhos,para funfar:
em SYNC=,comente ou remova a segunda e terceira linha de sync,deixe só o Sul Americano, assim>>>>>>

SYNC="rsync://rsync.samerica.gentoo.org/gentoo-portage
# rsync://gentoo.c3sl.ufpr.br/gentoo/ # rsync://gentoo.lcc.ufmg.br/gentoo-sources"
.
citação:

Queria entender esse repositório loongson. Por que é adicionado e tem que ser removido depois da compilação?

não é obrigado a remover, apenas a gente costuma remover overlays que não usa constantemente. se quiser overlays clássicos de sabayon, são

sabayon mesmo, e de Gentoo, sunrise, zugaina e berkano.
para ver a lista de todos os overlays que existem...

$ layman -L

Respondendo outras coisas... o overlay loogson é trunk, experimental... GLIBC2.11 e posteriores, não está nos repos oficiais do sbayon e so gentoo, pq ele é experimental, unstalble, e portanto está mascarado,masked!

o que estava acontecendo, é que vc estava instalando GTK+ e skype,muito novos...
além de serem rolling release, o sabayon e o gentoo são bleeding edge, tem pacotes unstable e trunk aos montes.

respondendo mais uma questão, seu make conf está correto e pode usar march native, se tiver GCC novo.
march native e compilação pro seu micro...
o melhor possivel para sua maquina.

GOSTEI DE VER QUE RESOLVEU,

portage dá trabalho, mas é fantástico. não?

gentoo dá trabalho instalar, mas para usar é igual, só que o gentoo é até mais fácil, pq ele tem menos pacotes,vc pode fazer emerge world, nele, no sabayon é complicado.

funtoo é parecido,mas funtoo tem portage git oriented,é mais rápido para atualizar. eu uso gentoo e funtoo também.

0 0

Quote

9. Re: AMD64... x86_64... libs 32... [RESOLVIDO]

albfneto
(usa openSUSE)

Enviado em 01/10/2010 - 23:39h

parte tá respondido no outro tópico.

citação:
Enfim, fica a lição: ao obter um erro leia com atenção o log e tente entender o erro e tudo melhor.

eu sempre falo, portage fala com vc! ele diz qual é o problema...

mini dica sobre sabayon. já deu prá ver que ele é trabalhoso, né?

se tiver muito espaço de HDD vazio, faça o seguinte, clone a partição raiz do sabayon e a /home, num pedaço vazio do HDD, se danar a outra instalação,é só copiar por cima e depois recolocar o grub...

quando pegar prática não perde mais. o meu, originalmente era um 5.0, feito de um 4.2. faz quase dois anos que não re-instalo..

mas quando comecei a usar sabayon e gentoo, rssrsr eu DESTRUÌ 6 instalações de Sabayon e 8 de Gentoo! rsrsrsrsrrs

outra coisa, totalmente atualizado, seu sabayon agora é o 5.4, que saiu ontem.
é um linux diferente, não?

0 0

Quote

10. Re: AMD64... x86_64... libs 32... [RESOLVIDO]

kinokrek
(usa Sabayon)

Enviado em 02/10/2010 - 03:08h

Diferente e instigante. No mundo de open source, é muito interessante ter uma distro tão atualizável assim.
Apesar desses problemas que tive, não foi mais penoso do que quando instalei o Kdenlive no kUbuntu, por exemplo. O que acontecia era até pior, pois, através do apt-get, havia muitos erros nos quais a capacidade de interação pra resolver era bem limitada... Gerava uma impotência. Mesmo com um aptitude, você poderia ter um Kdenlive instalado, mas era um Kdenlive problemático instalado. (Digo isso de uma experiência própria, mas já faz um bom tempo que isso ocorreu. E, também, ainda não utilizei tanto o Kdenlive aqui no Sabayon quanto no kUbuntu para perceber toda funcionalidade nele.) Eu mesmo só consegui instalar através do subversion... É que a integração com o MLT é problemática. Com um monte de dependência de lib de vídeo que muitas vezes só são resolvidas na raça... e olhe lá.
Sem falar que me parecia que instalações posteriores de outros programas colocavam a estabilidade do sistema e programas outros em risco por conta das versões das dependências... O portage parece respeitar/integrar isso tudo muito melhor...
Só frisando: é a minha impressão de pouco tempo de uso. Instalei alguns outros editores de vídeo já e estão todos que são uma gracinha!

O diretório raiz que você diz é o próprio "/" ou "/root"? Tenho um bom espaço aqui por enquanto, acho que vale a pena.
Sobre Sabayon com Gentoo. Ainda não, obrigado. Hehehehe... Me soa mais como aventura por enquanto do que necessidade ou que me dê muito benefício.

Pretendo agora conhecer melhor o sistema. Digo, quando tiver tempo. Tenho uma monografia para escrever e estou instalando o TeX para inovar. Gostei do conceito e me sinto cansado dos editores de texto convencionais. Parece que há macros para a ABTN também que podem facilitar as alterações.
Mas, quando tiver mais livre, pretendo começar a contribuir no desenvolvimento do sistema e dos programas. Como não sei nada de programação, vou para as traduções. Vi que o Sabayon já vem com ferramentas para isso até.

Vou tentar mais tarde os espelhos dos repositórios. Qualquer coisa, já sei como lidar melhor com o layman.

Abraço, Alberto. E mais uma vez, obrigado. Você me salvou. Essa do GLIBC 2.11 não tinha encontrado referência em lugar nenhum.

Ah... Só tenho um pé atrás com o Sabayon e é pelas próprias atualizações. Fico receoso que venha em alguma que comprometa algo, como aconteceu com o wine dessa vez.
Tem algum lugar no qual se concentram mais os bug reports do Sabayon? Pra se tomar conhecimento do que tá rolando?

0 0

Quote

11. Re: AMD64... x86_64... libs 32... [RESOLVIDO]

kinokrek
(usa Sabayon)

Enviado em 02/10/2010 - 03:09h

Ah! O Funtoo parece interessante.

0 0

Quote

12. Re: AMD64... x86_64... libs 32... [RESOLVIDO]

albfneto
(usa openSUSE)

Enviado em 04/10/2010 - 18:43h

citação:

"O diretório raiz que você diz é o próprio "/" ou "/root"? Tenho um bom espaço aqui por enquanto, acho que vale a pena"

mas claro,para copiar,precisa diminuir o espaço e deixar espaço livre,o que eu quiz dizer,éque num espaçolivre vc dria uma partição extended grande,e dentro dela uma outra / raiz e uma outra /home,e fa cópia CLONE do sabayon, mas outras partiçõesnãoa mesma,senão dana tudo.
ficaria algoassim,por ex.

sda1 windows
sda2 sabayon /
sda3 sabayon /home
sda4-5 extended e dentro:
sda6 sabayon /copia
sda7 sabayon /home copia

se perder o boot do sabayon normal,bastará re instalar o grub, apontando para sd6ao invés do sda2...

quanto a muitas atualizações quebrarem algo,bom, sempre arriscado nas rolling release,mas na duvida ,não atualize se o seu aplicativo for muito importatantepára seu uso,mas com prática, vc arruma do pepinos.os gentoos são empolgantes.

BUGS DO SABAYON FICAM AQUI:

Sabayon Bugzilla:

https://bugs.sabayon.org/

qualquer usuário pode reportar um bug isto é inclusive incentivado.
como o sabayon usa portage, está também sujeito as bugs do gentoo,procure na rede por Gentoo Bugzilla.

0 0

Quote