| 1 |
Em 27 de setembro de 2010 13:06, Daniel da Veiga |
| 2 |
<danieldaveiga@×××××.com> escreveu: |
| 3 |
> |
| 4 |
> Bom, o Ekiga teoricamente pode depender de: |
| 5 |
> |
| 6 |
> dev-libs/libsigc++ |
| 7 |
> net-nds/openldap |
| 8 |
> app-text/docbook-sgml-dtd |
| 9 |
> app-text/docbook-dsssl-stylesheets |
| 10 |
> app-text/xmlto |
| 11 |
> net-libs/ptlib |
| 12 |
> dev-libs/ilbc-rfc3951-0 |
| 13 |
> net-libs/opal |
| 14 |
> media-libs/gd |
| 15 |
> app-text/opensp |
| 16 |
> dev-libs/cyrus-sasl |
| 17 |
> media-gfx/graphviz |
| 18 |
> app-text/openjade |
| 19 |
> app-doc/doxygen |
| 20 |
> dev-util/gtk-doc |
| 21 |
> dev-libs/libdaemon |
| 22 |
> dev-libs/libgweather |
| 23 |
> gnome-extra/evolution-data-server |
| 24 |
> net-dns/avahi |
| 25 |
> dev-lang/perl |
| 26 |
> app-text/scrollkeeper |
| 27 |
> app-text/gnome-doc-utils |
| 28 |
> |
| 29 |
> De acordo com USEs e pacotes já instalados. Sabemos que as bibliotecas |
| 30 |
> ESTÃO instaladas, senão o portage iria puxar elas como dependência, e |
| 31 |
> também sabemos que alguma das bibliotecas está com problemas. |
| 32 |
> Teoricamente, se você recompilar todos os pacotes desta lista |
| 33 |
> instalados no seu sistema, um deles vai corrigir o problema. Estou |
| 34 |
> certo? |
| 35 |
|
| 36 |
Depende. O que está me intrigando é que o problema está em uma das |
| 37 |
libs (libcamel-1.2.so.14) produzidas pela compilação do |
| 38 |
evolution-data-server. E o |
| 39 |
que falta nessa lib é um referência e uma função da uma *outra lib* |
| 40 |
(nss), da qual o ekiga *não depende* (pelo menos não diretamente). Mas |
| 41 |
mesmo assim vou tentar recompilar os pacotes que você indicou. |
| 42 |
Posto aqui os resultados. E obrigado pela lista de pacotes! =) |
| 43 |
|
| 44 |
O ekiga depende do evolution-data-server, que por sua vez depende na |
| 45 |
nss/nspr caso a USE ssl esteja ligada. |
| 46 |
|
| 47 |
E no momento de compilar o ekiga ele sente falta de alguma símbolo |
| 48 |
dentro do "shared object" libcamel-1.2.so.14. Se olharem a mensagem de |
| 49 |
erro isso acontece no momento em que o binário principal do ekiga está |
| 50 |
sendo linkeditado, tanto que tem retorna o erro é o "ld", que foi |
| 51 |
chamado pelo gcc. |
| 52 |
|
| 53 |
O que me parece é que o evolution-data-server (e seus scripts de |
| 54 |
compilação: configure, makefiles, etc) esqueceram de adicionar uma |
| 55 |
parte da compilação desse "shared object". Mas aí vem a questão: Será |
| 56 |
que é papel do desenvolvedor do evolution-data-server colocar esses |
| 57 |
símbolos nos shared objetcs produzidos? Pra mim um simples "gcc -o |
| 58 |
<binario> -lnss -lnspr" já seria o suficiente para colocar os símbolos |
| 59 |
(e com versões corretas) dentro |
| 60 |
dos binários que estou compilando. |
| 61 |
|
| 62 |
Não cheguei a olhar o código do evolution-data-server (script de |
| 63 |
compilalção) para ver se ele explicitamente escolhe versões |
| 64 |
específicas para símbolos dentro de seus binários. |
| 65 |
|
| 66 |
Ainda acho que o problema está na produção da |
| 67 |
/usr/lib/libcamel-1.2.so.14 pois falta alguma coisa lá. E o mesmo se |
| 68 |
aplica para a /usr/lib/libnssutil3.so. |
| 69 |
|
| 70 |
Uma outra ideia, que ainda acho que vou executar, é compilar o |
| 71 |
evolution-data-server/ekiga sem usar os ebuilds (apenas compilar e não |
| 72 |
instalar) só para ver se obtenho resultados diferentes e para saber se |
| 73 |
o problema não está na forma como o ebuild está montando a linha do |
| 74 |
"./configure" dele. |
| 75 |
|
| 76 |
|
| 77 |
-- |
| 78 |
Dalton Barreto |
Archives