Isso parece um loader ausente . Breve história: o carregador dinâmico esperado pelo programa está faltando, e as mensagens de erro são enganosas neste caso. Como eu não acho que já discuti isso antes, deixe-me explicar a parte relevante da saída de ldd
. A maior parte é constituída de linhas da forma library_soname => /path/to/library_file
.
/lib/ld-lsb.so.3 => /lib/ld-linux.so.2 (0xb77bd000)
Entre as bibliotecas, vemos algo que não é uma biblioteca compartilhada: é o programa que carrega as bibliotecas compartilhadas. O programa está solicitando /lib/ld-lsb.so.3
, mas o kernel não o encontra, então ele relata “Nenhum arquivo ou diretório”. No entanto, ldd
encontra o carregador, porque ldd
é um script wrapper que chama um carregador embutido em um ambiente especial, e o carregador sempre relata seu próprio caminho, independentemente do caminho do carregador que o programa esperava.
Você tem /lib/ld-linux.so.2
em seu sistema, que é o local padrão de fato para o carregador ELF em sistemas Linux x86_32. O programa requer /lib/ld-lsb.so.3
, que é o local de jure .
Instale o suporte LSB mínimo da sua distribuição, por exemplo, o pacote lsb-core
no Debian. Se a sua distribuição não tem isso (a maioria faz), crie um link simbólico /lib/ld-lsb.so.3 -> ld-linux.so.2
. Em desespero, você pode chamar o carregador explicitamente: /lib/ld-linux.so.2 ./xls
.