“alternativas” para bibliotecas compartilhadas? Isso funciona mesmo?

“alternativas” para bibliotecas compartilhadas? Isso funciona mesmo?

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.soalternativa no Ubuntu 14.04 (e uma configuração semelhante, mas não idêntica, no 12.04). Quando eu uso o GCC com -lblaso 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-alternativeso esperado?

Responder1

A resolução do link simbólico é um recurso aqui. Ao resolver libblas.sopara libblas.so.3, o executável resultante é fixado em uma versão específica. (Mudanças na versão so, ou seja, 3in libblas.so.3ocorrem 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:

  1. Certifique-se de que seu aplicativo esteja vinculado ao libblas.so.3, como já está.
  2. No sistema de destino, crie um link simbólico do liblas.so real para o libblas.so.3nome 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
    

informação relacionada