Acabei de me deparar com um pequeno problema com ld , que não consigo explicar. Digamos que eu tenha compilado uma biblioteca no meu diretório home e instalado tudo em ~/root . O arquivo da biblioteca compartilhada pode ser encontrado em ~/root/usr/local/lib/libmylib.so .
Como ~/root/usr/local/lib não está no caminho de pesquisa do vinculador, defino LD_LIBRARY_PATH como sempre faço:
LD_LIBRARY_PATH="$HOME/root/usr/local/lib"
export LD_LIBRARY_PATH
E verifique se a biblioteca está disponível com:
$ ls $LD_LIBRARY_PATH/libmylib.so
/home/me/root/usr/local/lib/libmylib.so
Agora, se eu correr:
$ ld -lmylib --verbose
As linhas finais devem incluir algo como:
attempt to open /home/me/root/usr/local/lib/libmylib.so succeeded
-lmylib (/home/me/root/usr/local/lib/libmylib.so)
Exceto no meu caso, eles não. ld simplesmente não executa nenhuma pesquisa em /home/me/root . O conteúdo de LD_LIBRARY_PATH simplesmente nunca aparece na saída, o que sugere que ld está vergonhosamente ignorando a variável (e, na verdade, meu diretório nunca aparece em SEARCH_DIR antes na saída).
No entanto, se eu executar:
$ ld -L $LD_LIBRARY_PATH -lmylib --verbose
Eu obtenho as linhas acima e tudo corre bem, o que significa que não há nada de errado com a biblioteca ou o caminho da instalação.
Existe alguma circunstância na qual ld ignora LD_LIBRARY_PATH ? Eu verifiquei env e não consegui encontrar nenhuma outra variável relacionada ao vinculador ( RPATH , LIBRARY_PATH , LD_RUN_PATH , que foram todos testados). A configuração sob /etc/ld.so.* parece não fazer nada, exceto registrar alguns (outros) diretórios. A máquina executa o Scientific Linux 7.4, gcc 6.4 e ld 2.25.1. A biblioteca em questão é libxml++-3.0 .