Não é possível encontrar lib compartilhada em uma máquina amd64

Question

# /opt/dev/android-sdk/platforms/android-1.5/tools/aapt
/opt/dev/android-sdk/platforms/android-1.5/tools/aapt: error while loading shared libraries: libz.so.1: cannot open shared object file: No such file or directory

Em uma caixa i386, esse aapt é iniciado, mas não no amd64. /lib/libz.so.1 está lá em ambos os casos. Como vem?

    

Answer 1

Eu olhei para o dev-util / android-sdk e acontece que ele está puxando a emulação de aplicativos / emul-linux-x86-gtklibs como uma dependência.

    

Answer 2

Apenas tente: # emerge emul-linux-x86-baselibs, ele irá fornecer o libz.so.1 de 32 bits ... se isso falhar, tente ldd / path / to / aapt e forneça a saída, bem como a saída do seu ldconfig -v | grep libz

    

Answer 3

Parece que a ferramenta SDK aapt é um binário de 32 bits, por isso procura a versão de 32 bits da biblioteca libz, mas apenas encontra a de 64 bits. Você pode verificar isso com ldd . Acredito que, se você instalar o pacote emul-linux-x86-baselibs, ele fornecerá a biblioteca correta em /usr/lib32 .

    

Answer 4

o erro está na libz.so.1.2.3 de 32bit do emul-linux !!

eu acabei de construir uma versão em libbit de 32 bits e ele funciona - o aapt não lança o erro acima. se você estiver usando o gentoo - todas as versões libz do emul-linux-x86-baselibs possuem este problema (atualmente 20100915-r1 e 20110129)

aqui estão os passos que você precisa até que uma versão atualizada do emul-linux-baselibs seja lançada:

• obter zlib (1.2.5 ok)
• descompactar
• editar configuração

--- configure.old       2011-02-25 03:03:37.739491008 +0100
+++ configure   2011-02-25 03:03:51.760491008 +0100
@@ -105,8 +105,8 @@

 if test "$gcc" -eq 1 && ($cc -c $cflags $test.c) 2>/dev/null; then
   CC="$cc"
-  SFLAGS="${CFLAGS--O3} -fPIC"
-  CFLAGS="${CFLAGS--O3}"
+  SFLAGS="${CFLAGS--O3} -fPIC -m32"
+  CFLAGS="${CFLAGS--O3} -m32"
   if test $build64 -eq 1; then
     CFLAGS="${CFLAGS} -m64"
     SFLAGS="${SFLAGS} -m64"

• fazer
• mova libz.so.1.2.5 para / lib32

O problema é que, embora a versão de 64 bits que você compila tenha os seguintes campos no cabeçalho ELF:

  [ 5] .gnu.version      VERSYM           00000000000017be  000017be
  [ 6] .gnu.version_d    VERDEF           0000000000001890  00001890
  [ 7] .gnu.version_r    VERNEED          00000000000019e8  000019e8

a versão de 32 bits fornecida pelo emul-linux-x86-baselibs atual não possui o campo VERDEF, contém apenas

  [ 4] .gnu.version      VERSYM          00000d9c 000d9c 0000b4 02   A  2   0  2
  [ 5] .gnu.version_r    VERNEED         00000e50 000e50 000050 00   A  3   1  4

você pode verificar se a sua compilação personalizada de 32bit lib tem o campo VERDEF - o meu faz e eu me pergunto por que ele está faltando na distribuição do emul-linux.

respeita cmuelle8

ps: às vezes as mensagens de erro impressas por programas de computador estão corretas ..