arquivo de biblioteca é encontrado pelo ldconfig mas não pelo ldd

Question

Eu construí bibliotecas de aceleração OpenGL (libGL e libGLU) que eu mantenho em um diretório específico, /usr/lib/mali . Eu também tenho uma implementação de software do OpenGL que está instalado em /usr/lib/arm-linux-gnueabihf . Ambos os diretórios são adicionados a /etc/ld.so.conf com /usr/lib/mali vindo primeiro, para que os programas prefiram bibliotecas a partir dele.

ldconfig encontra todas as bibliotecas:

$ sudo ldconfig -v
/usr/lib/mali:
libGLU.so.1 -> libGLU.so.1
libGL.so.1.2.0 -> libGL.so.1
/usr/lib/arm-linux-gnueabihf:
libGL.so.1 -> libGL.so.1.5.08005
libGLU.so.1 -> libGLU.so.1.3.08005

A parte estranha é que ldconfig cria um link simbólico libGL.so.1.2.0 , mas não faz nada para libGLU . A saída ldd é ainda mais estranha:

ldd 'which glxgears'
libGLU.so.1 => /usr/lib/mali/libGLU.so.1 (0xb6e4a000)
libGL.so.1 => /usr/lib/arm-linux-gnueabihf/libGL.so.1 (0xb6bb5000)
libGL.so.1.2.0 => /usr/lib/mali/libGL.so.1.2.0 (0xb67f1000)

A saída sugere que libGLU seja obtido do diretório acelerado por hardware, enquanto libGL adere à implementação do software. libGL.so.1.2.0 também é carregado por algum motivo. No final, a implementação do software é usada quando eu executo glxgears .

Alguém pode me explicar o que está acontecendo? O que posso fazer para que minhas bibliotecas aceleradas por hardware sejam carregadas por padrão, sem remover ou sobrescrever as bibliotecas de software de /usr/lib/arm-linux-gnueabihf/ (elas são, na verdade, uma dependência de pacote)?

PS: as bibliotecas aceleradas por hardware funcionam quando adiciono /usr/lib/mali/ a LD_LIBRARY_PATH .

    

Answer 1

O problema estava de fato nas minhas configurações do Makefile. Inspecionar a biblioteca com objdump revelou a causa raiz:

$ objdump -p libGL.so.1 |grep SONAME
SONAME               libGL.so.1.2.0

ldd mostrou libGL.so.1 e libGL.so.1.2.0 , porque o primeiro foi importado por glxgears e o segundo foi importado pela minha implementação de libGLU , que foi criada com base na versão acelerada por hardware de libGL e, portanto, sabia que seu soname, libGL.so.1.2.0 .

A correção foi mudar o soname com -soname,libGL.so.1 .