“alternatives” para bibliotecas compartilhadas? Isso funciona mesmo?

2

Estou tentando vincular uma biblioteca compartilhada que tem várias implementações diferentes - especificamente blas, openblas e atlas, todos fornecem a mesma interface binária através da alternativa /usr/lib/libblas.so no Ubuntu 14.04 (e uma configuração similar, mas não idêntica, em 12.04 ). Quando eu uso o GCC com -lblas o linker parece realmente resolver através do link alternativo para a implementação real, então - por exemplo, se eu tiver o openblas instalado, ele irá se vincular ao binário do openblas e se eu instalar o executável resultante em um sistema em que o atlas está instalado, o vinculador dinâmico não carregará a biblioteca porque não verá o link alternativo.

Existe uma maneira de o GCC usar o link simbólico "alternativo" como o destino dl para que ele funcione como update-alternatives pretendido?

    
por Guss 05.11.2015 / 08:49

1 resposta

2

A resolução do Symlink é um recurso aqui. Ao resolver libblas.so para libblas.so.3 , o executável resultante é fixado em uma versão específica. (Alterações na versão so, ou seja, o 3 in libblas.so.3 ocorre quando a interface binária da biblioteca é alterada de forma incompatível, portanto, isso é desejado.

O problema parece ser que seu sistema de destino não tem um libblas.so.3 , então eu recomendo o seguinte:

  1. Verifique se seu aplicativo está vinculado a libblas.so.3 , como já é.
  2. No sistema de destino, crie um link simbólico a partir do libblas.so real para o nome libblas.so.3 requerido, de modo que esse link simbólico seja encontrado no LD_LIBRARY_PATH:

    mkdir ./mylib
    ln -s /usr/lib/libblas.so ./mylib/libblas.so.3
    LD_LIBRARY_PATH=$PWD/mylib:$LD_LIBRARY_PATH ./myexecutable
    
por 05.11.2015 / 11:41