algumas bibliotecas compartilhadas em / usr / local / lib não são encontradas, mas estão em / usr / lib

Question

Eu posso executar com sucesso um executável usando uma biblioteca compartilhada symlink'd em / usr / lib como assim -

sudo ln -s /lib/i386-linux-gnu/libcrypto.so.0.9.8 /usr/lib/libcrypto.so.4

No interesse de tornar isso mais fácil de manter, eu gostaria de movê-lo para / usr / local / lib -

sudo ln -s /lib/i386-linux-gnu/libcrypto.so.0.9.8 /usr/local/lib/libcrypto.so.4

Mas meu sistema parece ignorar esse link sym específico. / usr / local / lib está nas configurações relevantes de ld.so.conf e, de fato, está incluído na saída de ldconfig -v .

/usr/local/lib:
        libcrypto.so.0.9.8 -> libcrypto.so.4

Minha única pista até agora é que o ldconfig cria um link sym adicional de volta ao nome do arquivo ...

/usr/local/lib $ ls -l *so*
lrwxrwxrwx 1 root root 14 Aug 26 22:53 libcrypto.so.0.9.8 -> libcrypto.so.4
lrwxrwxrwx 1 root root 38 Aug 26 22:36 libcrypto.so.4 -> /lib/i386-linux-gnu/libcrypto.so.0.9.8
lrwxrwxrwx 1 root root 49 Aug 26 22:36 libiniparser.so.0 -> /usr/lib/x86_64-linux-gnu/samba/libiniparser.so.0

Na saída acima, por exemplo, o lib e o link para libiniparser.so.0 funcionam perfeitamente bem, incluídos em / usr / lib ou / usr / local / lib. A explicação mais simples seria que o ldconfig evita especificamente entradas que mudam o nome do arquivo da biblioteca, mas essa teoria não explica por que isso funciona em / usr / lib.

Qualquer ideia seria apreciada, obrigado.

    

Answer 1

Você pode adicionar mais caminhos adicionando basicamente outro arquivo de configuração ao /etc/ld.so.conf.d contendo os caminhos de diretório de seus novos locais e, em seguida, reconstruir o cache ou reinicializar. Ou você provavelmente pode usar o comando / sbin / ldconfig e fazer as manipulações dessa maneira.