Estou tentando vincular uma biblioteca compartilhada que possui várias implementações diferentes - especificamente blas, openblas e atlas fornecem a mesma interface binária por meio da /usr/lib/libblas.so
alternativa no Ubuntu 14.04 (e uma configuração semelhante, mas não idêntica, no 12.04). Quando eu uso o GCC com -lblas
o vinculador parece realmente resolver através do link alternativo para a implementação real, então - por exemplo, se eu tiver o openblas instalado, ele será vinculado ao binário real do openblas e se eu instalar o executável resultante em um sistema onde o atlas estiver instalado, o vinculador dinâmico não conseguirá carregar a biblioteca porque não verá o link alternativo.
Existe uma maneira de fazer com que o GCC use o link simbólico "alternativo" como destino dl para que ele realmente funcione conforme update-alternatives
o esperado?
Responder1
A resolução do link simbólico é um recurso aqui. Ao resolver libblas.so
para libblas.so.3
, o executável resultante é fixado em uma versão específica. (Mudanças na versão so, ou seja, 3
in libblas.so.3
ocorrem quando a interface binária da biblioteca muda de forma incompatível com versões anteriores, então isso é desejado.
O problema parece ser que seu sistema de destino não possui um arquivo libblas.so.3
, então recomendo o seguinte:
- Certifique-se de que seu aplicativo esteja vinculado ao
libblas.so.3
, como já está. No sistema de destino, crie um link simbólico do liblas.so real para o
libblas.so.3
nome necessário, de forma que esse link simbólico seja encontrado em LD_LIBRARY_PATH:mkdir ./mylib ln -s /usr/lib/libblas.so ./mylib/libblas.so.3 LD_LIBRARY_PATH=$PWD/mylib:$LD_LIBRARY_PATH ./myexecutable