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
.